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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
