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

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> > 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.

> > 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

Post the Cloud-Hypervisor patches to the list for review if you want
them included in OVMF.  out-of-tree patches lingering in some random
branch @ github do not matter.

> > > 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?).

Well, each VMM has different interfaces for guest <-> host
communication.  qemu/kvm uses fw_cfg.  Xen and Bhyve have something
different, and Cloud-Hypervisor seems to have something different again.

> 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. 

Sure.  If Cloud-Hypervisor wants use that (for both TDX and non-TDX
probably), fine.  Submit the patches and we can discuss details.

But why do you want switch qemu/kvm from fw_cfg to TD Hob?

> > 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. 

The code uses that unconditionally though and not only in case fw_cfg
is not available.

> 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.

I'm wondering what you are running on the host?  I assumed we are
discussing qemu/kvm as VMM, is that actually the case?  Or do you
use Cloud Hypervisor?

qemu doesn't provide a TD Hob.  So, when running qemu you probably have
some out-of-tree patches adding that.  Have you submitted them upstream?
What is the status?

I suspect you need to come up with some *very* good arguments to get
that accepted.  The need to bring parameters to the guest firmware is
the reason why fw_cfg exists in the first place ...

> 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.

fw_cfg is measured too (according to one of the tdx pdfs, don't remember
which one).

take care,
  Gerd