Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF

["James Bottomley" <jejb@linux.ibm.com>]

On Thu, 2021-06-03 at 13:51 +0000, Yao, Jiewen wrote:
> Hi, All
> We plan to do a design review for TDVF in OVMF package.
> 
> 
> The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11)
> is now available in blow link: 
> https://edk2.groups.io/g/devel/files/Designs/2021/0611.
> 
> The Bugzilla is https://bugzilla.tianocore.org/show_bug.cgi?id=3429

It looks like I'll be travelling that day, but should be able to attend
at least the first 45 minutes of the design review from the airport
lounge.

> You can have an offline review first. You comments will be warmly
> welcomed and we will continuously update the slides based on the
> feedbacks.

On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and
since TDX and SEV is an either/or, could we simply not rename both
pages and use them for either boot depending on what CPU type is
detected, so we only have two MEMFD pages, not four?

On your slide 13 Question: "Open: How will the QEMU find the metadata
location?" can't you just use the mechanism for SEV that's already
upstream in both QEMU and OVMF?

On slide 19, the mucking with the reset vector really worries me
because we don't have that much space to play with.  Given that you're
starting in 32 bit mode and can thus enter anywhere in the lower 4GB,
why not simply use a different and TDX specific entry point?

I'm not quite sure why you don't have a PEI phase, since TdxStartupLib
seems effectively to be PEI.

On all the Tcg2 changes: what about installing a vTPM driver that
simply translates to your MSRs?  That way we can use all the standard
TCG code as is?  Plus then we could do SEV-SNP measurement through an
actual vTPM running at higher VMPL or something.

Slide 41: IOMMU operation.  The implication is that you only transition
to unencrypted memory for DMA during the actual operation, so do I have
it correct that the guest writes DMA to encrypted memory, then the
iommu marks the region as unencrypted and transforms the memory to be
in the clear and then transforms it back after the DMA operation
completes?  Given that SEV operates quite happily with always in the
clear DMA buffers, this seems to have the potential to be a performance
problem, but what security does it gain?

James