[edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c

[Gerd Hoffmann]

  Hi,

> fw_cfg is just a KVM/QEMU specific way to pass some parameter, but not
> all parameter.  For example, OVMF today still get the memory size from
> CMOS.
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/PlatformPei/MemDetect.c#L278

Patches to fix that are on the list.

> In TDVF design, we choose the use TDX defined initial pointer to pass
> the initial memory information - TD_HOB, instead of CMOS region.
> Please help me understand what is the real concern here.

Well, qemu settled to the fw_cfg design or a number of reasons.  It is
pretty flexible for example.  The firmware can ask for the information
it needs at any time and can store it as it pleases.

I'd suggest to not take it for granted that an additional alternative
way to do basically the same thing will be accepted to upstream qemu.
Submit your patches to qemu-devel to discuss that.

> That means, if you get the same data twice from the fw_cfg, the TDVF
> must measure them twice. And TDVF may need handle the case that the
> data in first call is different with the data in second call.

Most fw_cfg entries are constant anyway, so we can easily avoid a second
call by caching the results of the first call if that helps TDVF.

> Using HOB in the initial pointer can be an alternative pattern to
> mitigate such risk. We just need measure them once then any component
> can use that. Also, it can help the people to evaluate the RTMR hash
> and TD event log data for the configuration in attestation flow,
> because the configuration is independent with the code execution flow.

Well, it covers only the memory map, correct?  All other configuration
is still loaded from fw_cfg.  I can't see the improvement here.

How do you pass the HOB to the guest?  Copy data to guest ram?  Map a
ro page into guest address space?  What happens on VM reset?

> Please be aware that confidential computing (TDX) changes the threat
> model completely, any input from VMM is considered as malicious.
> Current solution might be OK for normal OVMF. But it does not mean the
> same solution is still the best one for confidential computing use
> case.

Well, SEV seems to be happy with fw_cfg.
Any input from AMD on the topic?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79793): https://edk2.groups.io/g/devel/message/79793
Mute This Topic: https://groups.io/mt/84837914/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-