Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
James Bottomley
On Thu, 2021-06-03 at 13:51 +0000, Yao, Jiewen wrote:
Hi, AllIt 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 warmlyOn 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
|
|