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

["Yao, Jiewen" <jiewen.yao@intel.com>]

HI Ard and Gerd
I am not sure if I fully understand the argument here.

In TDX architecture, the VMM provides a pointer to the TD guest as initial parameter. We define the detail information there to be TD Hob. This solution is generic to all hypervisor.

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

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.



I understand the QEMU specific fw_cfg (https://github.com/qemu/qemu/blob/master/docs/specs/fw_cfg.txt).
If you want to use fw_cfg to pass some QEMU specific parameter, it is still possible.
For security reason, any input from the IO device must be measured by the TD guest.

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.
I can see potential attack surface there from architecture perspective.

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.

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.


Thank you
Yao Jiewen


> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Tuesday, August 24, 2021 8:56 PM
> To: Xu, Min M <min.m.xu@intel.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>; devel@edk2.groups.io; Ard
> Biesheuvel <ardb+tianocore@kernel.org>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Brijesh Singh <brijesh.singh@amd.com>; Erdem
> Aktas <erdemaktas@google.com>; James Bottomley <jejb@linux.ibm.com>;
> Yao, Jiewen <jiewen.yao@intel.com>; Tom Lendacky
> <thomas.lendacky@amd.com>
> Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c
> 
> On Tue, 24 Aug 2021 at 14:07, Xu, Min M <min.m.xu@intel.com> wrote:
> >
> > On August 20, 2021 3:23 PM, Gerd Hoffmann wrote:
> > > On Thu, Aug 19, 2021 at 02:27:16PM +0000, Min Xu wrote:
> > > > On August 19, 2021 2:50 PM, Gerd Hoffmann wrote:
> > > > > > +/**
> > > > > > +  In Tdx guest, some information need to be passed from host VMM
> > > > > > +to
> > > > > guest
> > > > > > +  firmware. For example, the memory resource, etc. These
> > > > > > + information are  prepared by host VMM and put in HobList which
> > > > > > + is described in
> > > > > TdxMetadata.
> > > > >
> > > > > What kind of information is passed to the guest here?
> > > > Please see
> > > >
> > > https://software.intel.com/content/dam/develop/external/us/en/document
> > > > s/tdx-virtual-firmware-design-guide-rev-1.pdf
> > > > Section 4.2 TD Hand-Off Block (HOB)
> > >
> > > So basically the physical memory map.
> > > qemu has etc/e820 for that.
> > >
> > > > > qemu has fw_cfg to pass information from the VMM to the guest
> > > firmware.
> > > > > What are the reasons to not use fw_cfg?
> > > > Not all the VMM support fw_cfg. Cloud-Hypervisor is the example.
> > >
> > > I can't see any support for Cloud-Hypervisor in OVMF.
> > Right that currently OVMF is not supported by Cloud-Hypervisor in Td guest.
> But we're
> > planning to support Cloud-Hypervisor to launch OVMF in Td guest and have
> done
> > some POC.
> 
> If cloud hypervisor support is coming to OVMF, please contribute those
> patches first, so they can be discussed in public. Adding special
> facilities here to accommodate out of tree functionality that may look
> completely differently after review is not the right way to approach
> this.
> 
> --
> Ard.
> 
> 
> > >
> > > Also FreeBSD's bhyve doesn't support fw_cfg either and has its own ways to
> > > detect memory.  Cloud-Hypervisor can surely do that too.
> > >
> > > So, why does this matter?
> > Yes, Cloud-Hypervisor has some POC to launch OVMF in Non-Td guest. In that
> POC
> > Cloud-Hypervisor leverage a 4k page in MEMFD and pass ACPI data to guest
> > Firmware in that memory.
> > https://github.com/cloud-hypervisor/edk2 "ch" branch
> > https://github.com/cloud-
> hypervisor/edk2/commit/52cb72a748ef70833100ca664f6c2a704c28a93f
> > >
> > > > https://github.com/cloud-hypervisor/cloud-hypervisor
> > > > TD Hob list gives Cloud-Hypervisor a chance to pass information to guest
> > > firmware.
> > > > For example, ACPI can be downloaded from QEMU via fw_cfg to firmware.
> > > > But Cloud-Hypervisor cannot pass ACPI via fw_cfg. In this situation,
> > > > TD Hob can resolve this problem.
> > >
> > > Sure, but again, why does this matter?  For qemu?
> > I don't quite understand the question here(For qumu?).
> > What I mean in my last answer is that TD Hob can resolve the problem when
> the host VMM
> > doesn't support fw_cfg communication mechanism.
> > For the host VMMs which doesn't support fw_cfg, when ACPI data need to be
> passed to guest
> > firmware, a 4k page (to hold ACPI data) is added in MEMFD. Then when
> SMBIOS is needed,
> > shall we add another page in MEMFD? If the ACPI data is too big to be held in a
> 4k page, then
> > the size of the reserved memory region in MEMFD is the restriction.
> > >
> > > I don't like the idea to have TDX take a completely different code paths.
> > > That increases the code complexity and makes testing harder for no good
> > > reason.
> > TD Hob is not a completely different code path. This is a useful supplement to
> the fw_cfg which
> > is not supported by some host VMM.
> > From another perspective TD Hob can be treated as a set of launch parameter
> by host VMM.
> > It provides the flexibility for the host VMM to bring up the guest firmware with
> more parameters.
> > Another benefit is that TD Hob can be measured into some secure register (for
> example, in TD guest
> > it is RTMR registers, like the TPM PCR) so that attestation can be done based
> on the measurement.
> >
> > Thanks Gerd for the comments. I am not sure if my explanation addressed your
> concern. Your comments
> > is always welcomed.
> > >
> >
> > Thanks!
> > Min