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@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Min Xu
>> Sent: Friday, June 11, 2021 6:30 AM
>> To: devel@edk2.groups.io; Yao, Jiewen <jiewen....@intel.com>;
>> r...@edk2.groups.io
>> Cc: j...@linux.ibm.com; Laszlo Ersek <ler...@redhat.com>; Brijesh Singh
>> <brijesh.si...@amd.com>; Tom Lendacky <thomas.lenda...@amd.com>;
>> erdemak...@google.com; c...@microsoft.com; bret.barke...@microsoft.com; Jon
>> Lange <jla...@microsoft.com>; Karen Noel <kn...@redhat.com>; Paolo Bonzini
>> <pbonz...@redhat.com>; Nathaniel McCallum <npmccal...@redhat.com>; Dr. David
>> Alan Gilbert <dgilb...@redhat.com>; Ademar de Souza Reis Jr.
>> <ar...@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@edk2.groups.io<mailto:devel@edk2.groups.io>
>> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Yao, Jiewen
>> Sent: Thursday, June 3, 2021 9:51 PM
>> To: r...@edk2.groups.io<mailto:r...@edk2.groups.io>;
>> devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>> Cc: j...@linux.ibm.com<mailto:j...@linux.ibm.com>; Laszlo Ersek
>> <ler...@redhat.com<mailto:ler...@redhat.com>>; Brijesh Singh
>> <brijesh.si...@amd.com<mailto:brijesh.si...@amd.com>>; Tom Lendacky
>> <thomas.lenda...@amd.com<mailto:thomas.lenda...@amd.com>>;
>> erdemak...@google.com<mailto:erdemak...@google.com>;
>> c...@microsoft.com<mailto:c...@microsoft.com>;
>> bret.barke...@microsoft.com<mailto:bret.barke...@microsoft.com>; Jon Lange
>> <jla...@microsoft.com<mailto:jla...@microsoft.com>>; Karen Noel
>> <kn...@redhat.com<mailto:kn...@redhat.com>>; Paolo Bonzini
>> <pbonz...@redhat.com<mailto:pbonz...@redhat.com>>; Nathaniel McCallum
>> <npmccal...@redhat.com<mailto:npmccal...@redhat.com>>; Dr. David Alan
>> Gilbert <dgilb...@redhat.com<mailto:dgilb...@redhat.com>>; Ademar de Souza
>> Reis Jr. <ar...@redhat.com<mailto:ar...@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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
