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

["Ard Biesheuvel" <ardb@kernel.org>]

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