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

Tue Jun 22 13:38:39 UTC 2021

On 06/22/21 15:34, Laszlo Ersek wrote:
> Hi,
> 
> On 06/11/21 08:37, Xu, Min M wrote:
>> In today's TianoCore Design Meeting we reviewed the Overview Section (from slide 1 to 20). Thanks much for the valuable feedbacks and comments. The meeting minutes will be sent out soon.
>>
>> To address the concerns of the *one binary* solution in previous discussion, we propose 2 Configurations for TDVF to upstream. (slide 6 - 8)
>>
>>
>>
>> Config-A:
>>
>>   *   Merge the *basic* TDVF feature to existing OvmfX64Pkg.dsc. (Align with existing SEV)
>>   *   Threat model: VMM is NOT out of TCB. (We don't make things worse.)
>>   *   The OvmfX64Pkg.dsc includes SEV/TDX/normal OVMF basic boot capability. The final binary can run on SEV/TDX/normal OVMF
>>   *   No changes to existing OvmfPkgX64 image layout.
>>   *   No need to add additional security features if they do not exist today
>>   *   No need to remove features if they exist today.
>>   *   RTMR is not supported
>>   *   PEI phase is NOT skipped in either Td or Non-Td
> 
> (so this is "Config-A / Option B", per slide 9 in the v0.9 slide deck)
> 
>>
>>
>>
>> Config-B:
>>
>>   *   Add a standalone IntelTdx.dsc to a TDX specific directory for a *full* feature TDVF. (Align with existing SEV)
>>   *   Threat model: VMM is out of TCB. (We need necessary change to prevent attack from VMM)
>>   *   IntelTdx.dsc includes TDX/normal OVMF basic boot capability. The final binary can run on TDX/normal OVMF
>>   *   It might eventually merge with AmdSev.dsc, but NOT at this point of time. And we don't know when it will happen. We need sync with AMD in the community, after both of us think the solutions are mature to merge.
>>   *   Need to add necessary security feature as mandatory requirement, such as RTMR based Trusted Boot support
>>   *   Need to remove unnecessary attack surfaces, such as network stack.
> 
> After reading the above, and checking slides 6 through 10 of the v0.9
> slide deck:
> 
> - I prefer Config-B (IntelTdx.dsc).

I should clarify: the relevant part of my preference is not that
"IntelTdx.dsc" contain the *complete* TDVF feature set. The relevant
part (for me) is that "OvmfPkgX64.dsc" *not* be over-complicated for the
sake of TDX, even considering only the "basic" TDVF feature set. It's
fine to implement TDX in two stages ("basic" and "complete"); my point
is that even "basic" should not over-complicate "OvmfPkgX64.dsc".

Thanks
Laszlo

> 
> This is in accordance with what I wrote earlier about "OvmfPkgX64.dsc"
> maintainability and regressions.
> 
> Additionally (given that a full-featured TDVF is the ultimate goal), I
> see the advance from "Config-A / option B" to "Config-B" a lot less
> *incremental* than the step from "OvmfPkgX64.dsc" to "AmdSev.dsc" was.
> 
> Put differently, I think that any TDX work targeted at "OvmfPkgX64.dsc"
> is going to prove less useful for the final "IntelTdx.dsc" than how
> reusable SEV work from "OvmfPkgX64.dsc" did for "AmdSev.dsc".
> 
> Put yet differently, I'm concerned that a part of the TDX work for
> "OvmfPkgX64.dsc" might be a waste, with an eye towards the ultimate TDVF
> feature set ("IntelTdx.dsc").
> 
> 
> - I could (very cautiously) live with "Config-A / option B" as the
> initial approach. However, we'de have to be ready to make the full split
> (the switch-over to "IntelTdx.dsc") at *any point* during development,
> in case something turns out to be too intrusive. (And yes, "too
> intrusive" is subjective.)
> 
> By this I mean that any particular patch towards "Config-A / option B"
> could cause me to ask, "please create IntelTdx.dsc now". Note that the
> later we make the switch the more painful it could be (= the more
> invested in "OvmfPkgX64.dsc" we could be, at that point).
> 
> For example, as I stated earlier, "OvmfPkg/AcpiPlatformDxe" is a driver
> where I'd like to see zero changes, for either SEV or TDX. If the TD
> Mailbox location has to be reported to the OS via the MADT, and QEMU
> cannot (or must not) populate that field in the MADT, then a separate,
> TDX-specific edk2 driver should locate the MADT (installed technically
> by "OvmfPkg/AcpiPlatformDxe", earlier), and update the field.
> 
> Thanks,
> Laszlo
> 
>> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Min Xu
>> Sent: Friday, June 11, 2021 6:30 AM
>> To: devel at edk2.groups.io; Yao, Jiewen <jiewen.yao at intel.com>; rfc at edk2.groups.io
>> Cc: jejb at linux.ibm.com; Laszlo Ersek <lersek at redhat.com>; Brijesh Singh <brijesh.singh at amd.com>; Tom Lendacky <thomas.lendacky at amd.com>; erdemaktas at google.com; cho at microsoft.com; bret.barkelew at microsoft.com; Jon Lange <jlange at microsoft.com>; Karen Noel <knoel at redhat.com>; Paolo Bonzini <pbonzini at redhat.com>; Nathaniel McCallum <npmccallum at redhat.com>; Dr. David Alan Gilbert <dgilbert at redhat.com>; Ademar de Souza Reis Jr. <areis at redhat.com>
>> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
>>
>> Hi, All
>> Thanks much for the valuable comments and discussion about the design.
>> We have updated the slides (v0.9) in below link. If some comments or concerns are not answered/addressed in the new slides, please don't hesitate to tell us. We do want to answer/address all the comments/concerns. But to be honest it is a rather complicated one and we appreciate your feedbacks.
>> https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review%28v0.9%29.pptx
>>
>> Thanks much!
>>
>> Xu Min
>>
>>
>> From: devel at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Yao, Jiewen
>> Sent: Thursday, June 3, 2021 9:51 PM
>> To: rfc at edk2.groups.io<mailto:rfc at edk2.groups.io>; devel at edk2.groups.io<mailto:devel at edk2.groups.io>
>> Cc: jejb at linux.ibm.com<mailto:jejb at linux.ibm.com>; Laszlo Ersek <lersek at redhat.com<mailto:lersek at redhat.com>>; Brijesh Singh <brijesh.singh at amd.com<mailto:brijesh.singh at amd.com>>; Tom Lendacky <thomas.lendacky at amd.com<mailto:thomas.lendacky at amd.com>>; erdemaktas at google.com<mailto:erdemaktas at google.com>; cho at microsoft.com<mailto:cho at microsoft.com>; bret.barkelew at microsoft.com<mailto:bret.barkelew at microsoft.com>; Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>; Karen Noel <knoel at redhat.com<mailto:knoel at redhat.com>>; Paolo Bonzini <pbonzini at redhat.com<mailto:pbonzini at redhat.com>>; Nathaniel McCallum <npmccallum at redhat.com<mailto:npmccallum at redhat.com>>; Dr. David Alan Gilbert <dgilbert at redhat.com<mailto:dgilbert at redhat.com>>; Ademar de Souza Reis Jr. <areis at redhat.com<mailto:areis at redhat.com>>
>> Subject: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
>>
>> 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
>>
>>
>>
>> You can have an offline review first. You comments will be warmly welcomed and we will continuously update the slides based on the feedbacks.
>>
>>
>>
>> Thank you
>>
>> Yao Jiewen
>>
>>
>>
>>
>>
>> 
>>
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76837): https://edk2.groups.io/g/devel/message/76837
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]
-=-=-=-=-=-=-=-=-=-=-=-