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

[Min Xu]

On 06/09/2021 12:01 AM, James Bottomley wrote:
> 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.
>
Thanks much James!
 
> 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?
>
Agree. A good idea.
> 
> 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?
>
I have answered this comments in my last answer to Laszlo.

>
> 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?
>
If TDVF has a separate DSF/FDF, this is not a problem.

I once think about below solution, that different mode goes to its specific entry point.
For example:
    real-mode goes to 0xfffffff0, 
    protected-mode goes to 0xffffffe0, 
    long-mode goes to 0xffffffd0. 

Let's wait for a conclusion to the *one binary* solution.

> 
> I'm not quite sure why you don't have a PEI phase, since TdxStartupLib seems
> effectively to be PEI.
>
I will answer this comments in my next mail. Thanks
>
> 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.
>
I don’t quite understand "installing a vTPM driver". Can you explain more about
the vTpm driver? Do you mean TDX specific RTMR extending is implemented in the
"vTpm driver" ?
 
>
> 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?
> 
See my comments in my last answer to Laszlo.

Thanks!
Min


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