Date
21 - 40 of 42
[edk2-devel] RFC: design review for TDVF in OVMF
Min Xu <min.m.xu@...>
On 06/09/2021 12:01 AM, James Bottomley wrote:
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.
the vTpm driver? Do you mean TDX specific RTMR extending is implemented in the
"vTpm driver" ?
Thanks!
Min
It looks like I'll be travelling that day, but should be able to attend at least theThanks much James!
first 45 minutes of the design review from the airport lounge.
On TdMailbox and TdHob, we already have two SEV pages in the MEMFD andAgree. A good idea.
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?
I have answered this comments in my last answer to Laszlo.
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?
If TDVF has a separate DSF/FDF, this is not a problem.
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 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 will answer this comments in my next mail. Thanks
I'm not quite sure why you don't have a PEI phase, since TdxStartupLib seems
effectively to be PEI.
I don’t quite understand "installing a vTPM driver". Can you explain more about
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.
the vTpm driver? Do you mean TDX specific RTMR extending is implemented in the
"vTpm driver" ?
See my comments in my last answer to Laszlo.
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?
Thanks!
Min
Laszlo Ersek
On 06/09/21 02:58, Xu, Min M wrote:
[...]
Thanks,
Laszlo
On 06/09/2021 3:33 AM, Laszlo wrote:On 06/08/21 18:01, James Bottomley wrote:
This is my understanding, yes; James will know more details though.So my understanding to this solution is that:On your slide 13 Question: "Open: How will the QEMU find the metadataI think I made the same comment, in different words. (Point (12) at
location?" can't you just use the mechanism for SEV that's already
upstream in both QEMU and OVMF?
<https://listman.redhat.com/archives/edk2-devel-archive/2021-
June/msg00143.html>.)
1) GUID-ed structure chain is started from a fixed GPA in ResetVector.
2) Append a TDX-specific GUID-ed structure in the chain
3) Qemu search the GUID-ed chain from the fixed GPA and find the TDX-specific
GUID-ed structure based on TDX-specific GUID.
Is the expected process for QEMU?
[...]
Thanks,
Laszlo
James Bottomley <jejb@...>
On Wed, 2021-06-09 at 02:01 +0000, Xu, Min M wrote:
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit real and 64 bit entry
points. This would also come with the added advantage that we can scan
the OVMF binary to see what entry points it supports.
James
On 06/09/2021 12:01 AM, James Bottomley wrote:[...]
That would cut across the ApEntrypoint and the guidedStructureEnd.On slide 19, the mucking with the reset vector really worries meIf TDVF has a separate DSF/FDF, this is not a problem.
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 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.
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit real and 64 bit entry
points. This would also come with the added advantage that we can scan
the OVMF binary to see what entry points it supports.
James
James Bottomley <jejb@...>
On Wed, 2021-06-09 at 13:00 +0200, Laszlo Ersek wrote:
table, so you can tell if it's present or not by looking for the table
guid (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If you find
that, it gives you the size of the table as the u16 preceding the GUID.
All entries are of the form
<variable size data> <u16 tot len inc guid> <guid>
You can see how it works in
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
Beginning around line 35.
In QEMU you want the function pc_system_ovmf_table_find() which is in
hw/i386/pc_sysfw.c and finds entries by guid.
James
On 06/09/21 02:58, Xu, Min M wrote:Pretty much, yes. The guided structure is designed as a backwardsOn 06/09/2021 3:33 AM, Laszlo wrote:This is my understanding, yes; James will know more details though.On 06/08/21 18:01, James Bottomley wrote:So my understanding to this solution is that:On your slide 13 Question: "Open: How will the QEMU find theI think I made the same comment, in different words. (Point (12)
metadata location?" can't you just use the mechanism for SEV
that's already upstream in both QEMU and OVMF?
at
<https://listman.redhat.com/archives/edk2-devel-archive/2021-
June/msg00143.html>.)
1) GUID-ed structure chain is started from a fixed GPA in
ResetVector.
2) Append a TDX-specific GUID-ed structure in the chain
3) Qemu search the GUID-ed chain from the fixed GPA and find the
TDX-specific GUID-ed structure based on TDX-specific GUID.
Is the expected process for QEMU?
table, so you can tell if it's present or not by looking for the table
guid (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffffffd0. If you find
that, it gives you the size of the table as the u16 preceding the GUID.
All entries are of the form
<variable size data> <u16 tot len inc guid> <guid>
You can see how it works in
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
Beginning around line 35.
In QEMU you want the function pc_system_ovmf_table_find() which is in
hw/i386/pc_sysfw.c and finds entries by guid.
James
Paolo Bonzini <pbonzini@...>
On 09/06/21 16:28, James Bottomley wrote:
The GUIDed structure can either include the entry point code; or it could have room for a couple 8-byte pointers since any fixed-size area in the GUIDed structure would be just a jump anyway.
Paolo
That would cut across the ApEntrypoint and the guidedStructureEnd.Isn't the initial state included in the save area just like for SEV-ES? So it's not even QEMU, but rather some external tool that builds the encrypted image, that needs to understand that GUIDed structure.
However, nothing says anything in the reset vector guided structure has
to be data ... so it could equally well be code. That means we can do
guid based entries that contain the 32 bit real and 64 bit entry
points. This would also come with the added advantage that we can scan
the OVMF binary to see what entry points it supports.
The GUIDed structure can either include the entry point code; or it could have room for a couple 8-byte pointers since any fixed-size area in the GUIDed structure would be just a jump anyway.
Paolo
James Bottomley <jejb@...>
On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote:
the address and size of the secrets page and the other gives the
address of the ES work area page that's used for AP reset.
introspectable. The current consumer is QEMU, but I see no reason why
other tools might not use this mechanism as well.
much anything with the data contents with the only caveat that it's
currently constructed by an asm file, so we don't quite have the full
macro power of C available. However, symbol resolution is definitely
possible and quite easy.
James
On 09/06/21 16:28, James Bottomley wrote:Initial state of what? We currently have two entries: one points toThat would cut across the ApEntrypoint and the guidedStructureEnd.Isn't the initial state included in the save area just like for SEV-
However, nothing says anything in the reset vector guided structure
has to be data ... so it could equally well be code. That means we
can do guid based entries that contain the 32 bit real and 64 bit
entry points. This would also come with the added advantage that
we can scan the OVMF binary to see what entry points it supports.
ES?
the address and size of the secrets page and the other gives the
address of the ES work area page that's used for AP reset.
So it's not even QEMU, but rather some external tool that buildsYes, it's really to make the configuration of the OVMF blob somewhat
the encrypted image, that needs to understand that GUIDed structure.
introspectable. The current consumer is QEMU, but I see no reason why
other tools might not use this mechanism as well.
The GUIDed structure can either include the entry point code; or itWell, exactly ... depending on what the requirement is we can do pretty
could have room for a couple 8-byte pointers since any fixed-size
area in the GUIDed structure would be just a jump anyway.
much anything with the data contents with the only caveat that it's
currently constructed by an asm file, so we don't quite have the full
macro power of C available. However, symbol resolution is definitely
possible and quite easy.
James
Erdem Aktas <erdemaktas@...>
Hi all,
Sorry for the late reply. I like to add some clarification on "one
binary". I feel like the way everyone uses the term "one binary" in
the email threads is causing some confusion.
As I have tried to explain before, we are not looking for everything
in a single binary. As Laszlo has mentioned in a lot of places, some
additional features are TDX specific and not worth pushing into the
OvmfPkgX64.dsc.
What we are asking with "one binary" is: Simply enabling OVMF + a
guest OS to boot in a TDX domain without breaking any existing
functionality. Intel should put everything else (specifically related
to remote attestation) in a separate platform configuration. This
aligns well with Laszlo's perspective and it is similar to what AMD is
doing as far as I can see.
Enabling a minimum functionality in OvmfPkgX64.dsc without breaking
existing functionality will allow a lot of flexibility for us for
integration/testing and productionization.
A separate platform configuration file can be used to provide all the
security guarantees that TDX provides.
Based on the above clarification, Intel has updated their slides
accordingly - I really appreciate their hard work and community
collaboration spirit. I am hoping that this clears up the confusion.
On Thu, Jun 3, 2021 at 9:12 AM Laszlo Ersek <lersek@...> wrote:
TCB but I agree with Laszlo, OvmfPkgX64 is not the best place to do
this. The existing secure boot flow should not be changed. Any
additional improvement to reduce the TCB can go TDX specific platform
communication.
table should solve this issue. And I do not think there is any
dependency on SEV patches. I am assuming anyone can easily add an
entry to the GUIDed table and based on other responses, this seems
like a trivial implementation.
the AP reset vector (jump address) address.
to reduce the TCB but not necessary to boot a guest with TDX is
enabled. Again it goes under the topic of what is minimum and what is
secure and TDX specific platform configuration.
So I think it should not be part of OvmfPkgX64.dsc
On Thu, Jun 3, 2021 at 4:19 PM Yao, Jiewen <jiewen.yao@...> wrote:
OvmfPkgX64.dsc to enable the TDX and what is required for removing the
VMM from the TCB. Anything improving security guarantees can go to TDX
specific configuration files.
On Sun, Jun 6, 2021 at 5:49 AM Xu, Min M <min.m.xu@...> wrote:
Sorry for the late reply. I like to add some clarification on "one
binary". I feel like the way everyone uses the term "one binary" in
the email threads is causing some confusion.
As I have tried to explain before, we are not looking for everything
in a single binary. As Laszlo has mentioned in a lot of places, some
additional features are TDX specific and not worth pushing into the
OvmfPkgX64.dsc.
What we are asking with "one binary" is: Simply enabling OVMF + a
guest OS to boot in a TDX domain without breaking any existing
functionality. Intel should put everything else (specifically related
to remote attestation) in a separate platform configuration. This
aligns well with Laszlo's perspective and it is similar to what AMD is
doing as far as I can see.
Enabling a minimum functionality in OvmfPkgX64.dsc without breaking
existing functionality will allow a lot of flexibility for us for
integration/testing and productionization.
A separate platform configuration file can be used to provide all the
security guarantees that TDX provides.
Based on the above clarification, Intel has updated their slides
accordingly - I really appreciate their hard work and community
collaboration spirit. I am hoping that this clears up the confusion.
On Thu, Jun 3, 2021 at 9:12 AM Laszlo Ersek <lersek@...> wrote:
My point is that the "one binary" that the slide deck refers to (i.e.,This is what we are asking as a single binary.
OvmfPkgX64.dsc) might prove OK for utilizing the Intel TDX *technology*
in itself. Simply enabling OVMF + a guest OS to boot in a TDX domain.
But "OvmfPkgX64.dsc" is *not* the "one binary" that is suitable forThis is okay for us.
remote attestation, which has a much broader scope, involving multiple
computers, networking, deployment, guest-owner/host-owner separation,
whatever. For the latter, we needed a separate platform anyway, even
with only SEV in mind; that's why "OvmfPkg/AmdSev/AmdSevX64.dsc" exists.
(10) This slide (slide 11) basically describes an intrusiveEmbedding secure keys might be a good idea to remove the VMM from the
reorganization of "OvmfPkgX64.fdf". I don't think I can agree to that.
While confidential computing is important, it is not relevant for many
users. Even if we don't cause outright regressions for existent setups,
the maintenance cost of the traditional OVMF platform will skyrocket.
The big bunch of areas that SEV-ES introduced to MEMFD is already a big
complication. I'd feel much better if we could isolate all that to a
dedicated "remote attested boot" firmware platform, and not risk the
functionality and maintenance of the traditional platform. I think this
ties in with my comment (1).
For example, seeing a configuration firmware volume (CFV) with secure
boot keys embedded, in the "usual" FDF, will confuse lots of people, me
included. In the traditional OVMF use case, we use a different method:
namely OvmfPkg/EnrollDefaultKeys, for "priming" a variable store
template, in the build environment.
TCB but I agree with Laszlo, OvmfPkgX64 is not the best place to do
this. The existing secure boot flow should not be changed. Any
additional improvement to reduce the TCB can go TDX specific platform
communication.
(12) My comment is that the GUID-ed structure chain already starts at aI think there is a confusion in slide #13. I agree that the GUIDed
fixed GPA (the "AMD SEV option"). Ordering between GUID-ed structures is
irrelevant, so any TDX-specific structures should be eligible for
appending to, prepending to, or intermixing with, other (possibly
SEV-specific) structures. There need not be a separate entry point, just
different GUIDS.
table should solve this issue. And I do not think there is any
dependency on SEV patches. I am assuming anyone can easily add an
entry to the GUIDed table and based on other responses, this seems
like a trivial implementation.
(13) Regarding "4G-0x20[0x10] is OVMF AP reset vector (used in OVMFI am guessing what Intel refers to is "SEV-ES resetblock" which sets
implementation)" -- I think this is a typo: this "AP reset vector" is
*not* used in OVMF. To my knowledge, it is a vestige from the UefiCpuPkg
reset vector. In OVMF, APs are booted via MpInitLib (in multiple
firmware phases), using INIT-SIPI-SIPI, and the reset vector for the
APs, posited through those IPIs, is prepared in low RAM.
the AP reset vector (jump address) address.
(22) EmuVariableFvbRuntimeDxeCopying configuration variables into configuration volume is "good"
Ouch, this is an unpleasant surprise.
First, if you know for a fact that pflash is not part of the *board* in
any TDX setup, then pulling
to reduce the TCB but not necessary to boot a guest with TDX is
enabled. Again it goes under the topic of what is minimum and what is
secure and TDX specific platform configuration.
So I think it should not be part of OvmfPkgX64.dsc
On Thu, Jun 3, 2021 at 4:19 PM Yao, Jiewen <jiewen.yao@...> wrote:
I think we should separate what is minimum which should go to the
Hi Laszlo.
To clarify your "one binary" feedback below, do you mean you suggest A) create a separate DSC (for example OvmfPkg/ConfidentialComputing.dsc) for a full solution including AMD SEC + Intel TDX + NonConfidentialComputing?
Or B) to create a standalone DSC for Intel TDX (for example, create a OvmfPkg/IntelTdx/IntelTdxXS64.dsc) ?
To me, A) does not change too much, we just create another DSC file - that is it.
Then the original OvmfPkgX64.dsc will only be used for POC/Testing purpose. It does not provide any security guarantee.
(The threat model is: we don't trust VMM. Without attestation, you don't know if VMM modified the OVMF.)
OvmfPkgX64.dsc to enable the TDX and what is required for removing the
VMM from the TCB. Anything improving security guarantees can go to TDX
specific configuration files.
On Sun, Jun 6, 2021 at 5:49 AM Xu, Min M <min.m.xu@...> wrote:
On June 6, 2021 7:30 PM, Michael Brown Wrote:On 06/06/2021 03:03, Min Xu wrote:In our first version of TDVF, a static 5-level page table is used. It is simple andThe "one binary" decision isn't relevant here, is it? It would make more(11) "Page table should support both 4-level and 5-level page table"Yes, 5-level paging is a strict requirement for TDX. I would wait for
As a general development strategy, I would suggest building TDX
support in small, well-isolated layers. 5-level paging is not enabled
(has never been tested, to my knowledge) with OVMF on QEMU/KVM,
regardless of confidential computing, for starters. If 5-level paging
is a strict requirement for TDX, then it arguably needs to be
implemented independently of TDX, at first. So that the common edk2
architecture be at least testable on QEMU/KVM with 5-level paging
enabled.
the conclusion of the *one binary*.
sense to implement 5-level paging within the base EDK2 architecture. This
would allow that feature to be tested in isolation from TDX (and
consequently tested more widely), and would reduce the distance between
standard builds and TDX builds.
straight forward. But for *one binary* solution, we have to consider the compatibility
with the current 4-level page table. That's why I said "I would wait for the conclusion
of the *one binary*"
Thanks for the suggestion. We will discuss the it internally first.Michael
Min Xu <min.m.xu@...>
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 <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
Sent: Thursday, June 3, 2021 9:51 PM
To: rfc@edk2.groups.io; devel@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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
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 <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
Sent: Thursday, June 3, 2021 9:51 PM
To: rfc@edk2.groups.io; devel@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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
James Bottomley <jejb@...>
On Thu, 2021-06-10 at 22:30 +0000, Xu, Min M wrote:
entry.
James
Hi, AllWhat's the url of the meeting? Apparently it isn't in the calendar
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
entry.
James
Yao, Jiewen
Hi James.
I attached the invitation and copied all content below:
==================================
## TOPIC
1. NA
For more info, see here: https://www.tianocore.org/design-meeting/
---
## Microsoft Teams meeting
### Join on your computer or mobile app
[Click here to join the meeting](https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc27-3d06c576cc19%22%7d)
### Join with a video conferencing device
teams@...
Video Conference ID: 119 715 416 0
[Alternate VTC dialing instructions](https://conf.intel.com/teams/?conf=1197154160&ivr=teams&d=conf.intel.com&test=test_call)
[Learn More](https://aka.ms/JoinTeamsMeeting) | [Meeting options](https://teams.microsoft.com/meetingOptions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4@thread.v2&messageId=0&language=en-US)
==================================
toggle quoted message
Show quoted text
I attached the invitation and copied all content below:
==================================
## TOPIC
1. NA
For more info, see here: https://www.tianocore.org/design-meeting/
---
## Microsoft Teams meeting
### Join on your computer or mobile app
[Click here to join the meeting](https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc27-3d06c576cc19%22%7d)
### Join with a video conferencing device
teams@...
Video Conference ID: 119 715 416 0
[Alternate VTC dialing instructions](https://conf.intel.com/teams/?conf=1197154160&ivr=teams&d=conf.intel.com&test=test_call)
[Learn More](https://aka.ms/JoinTeamsMeeting) | [Meeting options](https://teams.microsoft.com/meetingOptions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4@thread.v2&messageId=0&language=en-US)
==================================
-----Original Message-----
From: James Bottomley <jejb@...>
Sent: Friday, June 11, 2021 9:33 AM
To: Xu, Min M <min.m.xu@...>; devel@edk2.groups.io; Yao, Jiewen
<jiewen.yao@...>; rfc@edk2.groups.io
Cc: Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>;
Tom Lendacky <thomas.lendacky@...>; erdemaktas@...;
cho@...; bret.barkelew@...; Jon Lange
<jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini
<pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr.
David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr.
<areis@...>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
On Thu, 2021-06-10 at 22:30 +0000, Xu, Min M wrote:Hi, Allhttps://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review
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.
%28v0.9%29.pptx
What's the url of the meeting? Apparently it isn't in the calendar
entry.
James
James Bottomley <jejb@...>
On Fri, 2021-06-11 at 01:36 +0000, Yao, Jiewen wrote:
dial in?
James
Hi James.Apparently it's not possible to join from a web browser: is there a
I attached the invitation and copied all content below:
==================================
## TOPIC
1. NA
For more info, see here: https://www.tianocore.org/design-meeting/
---
## Microsoft Teams meeting
### Join on your computer or mobile app
[Click here to join the meeting](
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc27-3d06c576cc19%22%7d
)
dial in?
James
James Bottomley <jejb@...>
On Thu, 2021-06-10 at 21:38 -0400, James Bottomley wrote:
comments in the email thread anyway and I'll be boarding my next flight
soon.
However, next time can we hold meetings with usable web based meeting
technologies, like zoom or webex? It's not feasible to demand
downloading gigabytes of app from a remote location ... even when it
works, which this one doesn't seem to do: the app download just keeps
going back to the meeting screen.
Thanks,
James
On Fri, 2021-06-11 at 01:36 +0000, Yao, Jiewen wrote:In the absence of a dial in, I'll view the recording. I did most of myHi James.Apparently it's not possible to join from a web browser: is there a
I attached the invitation and copied all content below:
==================================
## TOPIC
1. NA
For more info, see here: https://www.tianocore.org/design-meeting/
---
## Microsoft Teams meeting
### Join on your computer or mobile app
[Click here to join the meeting](
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc27-3d06c576cc19%22%7d
)
dial in?
comments in the email thread anyway and I'll be boarding my next flight
soon.
However, next time can we hold meetings with usable web based meeting
technologies, like zoom or webex? It's not feasible to demand
downloading gigabytes of app from a remote location ... even when it
works, which this one doesn't seem to do: the app download just keeps
going back to the meeting screen.
Thanks,
James
Min Xu <min.m.xu@...>
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
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.
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.yao@...>; rfc@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: jejb@...<mailto:jejb@...>; Laszlo Ersek <lersek@...<mailto:lersek@...>>; Brijesh Singh <brijesh.singh@...<mailto:brijesh.singh@...>>; Tom Lendacky <thomas.lendacky@...<mailto:thomas.lendacky@...>>; erdemaktas@...<mailto:erdemaktas@...>; cho@...<mailto:cho@...>; bret.barkelew@...<mailto:bret.barkelew@...>; Jon Lange <jlange@...<mailto:jlange@...>>; Karen Noel <knoel@...<mailto:knoel@...>>; Paolo Bonzini <pbonzini@...<mailto:pbonzini@...>>; Nathaniel McCallum <npmccallum@...<mailto:npmccallum@...>>; Dr. David Alan Gilbert <dgilbert@...<mailto:dgilbert@...>>; Ademar de Souza Reis Jr. <areis@...<mailto:areis@...>>
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
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
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.
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.yao@...>; rfc@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: jejb@...<mailto:jejb@...>; Laszlo Ersek <lersek@...<mailto:lersek@...>>; Brijesh Singh <brijesh.singh@...<mailto:brijesh.singh@...>>; Tom Lendacky <thomas.lendacky@...<mailto:thomas.lendacky@...>>; erdemaktas@...<mailto:erdemaktas@...>; cho@...<mailto:cho@...>; bret.barkelew@...<mailto:bret.barkelew@...>; Jon Lange <jlange@...<mailto:jlange@...>>; Karen Noel <knoel@...<mailto:knoel@...>>; Paolo Bonzini <pbonzini@...<mailto:pbonzini@...>>; Nathaniel McCallum <npmccallum@...<mailto:npmccallum@...>>; Dr. David Alan Gilbert <dgilbert@...<mailto:dgilbert@...>>; Ademar de Souza Reis Jr. <areis@...<mailto:areis@...>>
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
Laszlo Ersek
Hi,
On 06/11/21 08:37, Xu, Min M wrote:
slide deck:
- I prefer Config-B (IntelTdx.dsc).
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
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.(so this is "Config-A / Option B", per slide 9 in the v0.9 slide deck)
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
After reading the above, and checking slides 6 through 10 of the v0.9
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.
slide deck:
- I prefer Config-B (IntelTdx.dsc).
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.yao@...>; rfc@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: jejb@...<mailto:jejb@...>; Laszlo Ersek <lersek@...<mailto:lersek@...>>; Brijesh Singh <brijesh.singh@...<mailto:brijesh.singh@...>>; Tom Lendacky <thomas.lendacky@...<mailto:thomas.lendacky@...>>; erdemaktas@...<mailto:erdemaktas@...>; cho@...<mailto:cho@...>; bret.barkelew@...<mailto:bret.barkelew@...>; Jon Lange <jlange@...<mailto:jlange@...>>; Karen Noel <knoel@...<mailto:knoel@...>>; Paolo Bonzini <pbonzini@...<mailto:pbonzini@...>>; Nathaniel McCallum <npmccallum@...<mailto:npmccallum@...>>; Dr. David Alan Gilbert <dgilbert@...<mailto:dgilbert@...>>; Ademar de Souza Reis Jr. <areis@...<mailto:areis@...>>
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
Laszlo Ersek
On 06/22/21 15:34, Laszlo Ersek wrote:
"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
Hi,I should clarify: the relevant part of my preference is not that
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.(so this is "Config-A / Option B", per slide 9 in the v0.9 slide deck)
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-TdAfter reading the above, and checking slides 6 through 10 of the v0.9
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.
slide deck:
- I prefer Config-B (IntelTdx.dsc).
"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,
LaszloFrom: 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.yao@...>; rfc@edk2.groups.io
Cc: jejb@...; Laszlo Ersek <lersek@...>; Brijesh Singh <brijesh.singh@...>; Tom Lendacky <thomas.lendacky@...>; erdemaktas@...; cho@...; bret.barkelew@...; Jon Lange <jlange@...>; Karen Noel <knoel@...>; Paolo Bonzini <pbonzini@...>; Nathaniel McCallum <npmccallum@...>; Dr. David Alan Gilbert <dgilbert@...>; Ademar de Souza Reis Jr. <areis@...>
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: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: jejb@...<mailto:jejb@...>; Laszlo Ersek <lersek@...<mailto:lersek@...>>; Brijesh Singh <brijesh.singh@...<mailto:brijesh.singh@...>>; Tom Lendacky <thomas.lendacky@...<mailto:thomas.lendacky@...>>; erdemaktas@...<mailto:erdemaktas@...>; cho@...<mailto:cho@...>; bret.barkelew@...<mailto:bret.barkelew@...>; Jon Lange <jlange@...<mailto:jlange@...>>; Karen Noel <knoel@...<mailto:knoel@...>>; Paolo Bonzini <pbonzini@...<mailto:pbonzini@...>>; Nathaniel McCallum <npmccallum@...<mailto:npmccallum@...>>; Dr. David Alan Gilbert <dgilbert@...<mailto:dgilbert@...>>; Ademar de Souza Reis Jr. <areis@...<mailto:areis@...>>
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
Min Xu <min.m.xu@...>
On 06/22/2021 9:35 PM, Laszlo wrote:
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review-AcpiPlatformDxe.pptx
Because MailboxAddress in MADT table is determined in runtime in Tdx, so we
separate the update of the MADT table in TdxDxe driver and keep AcpiPlatformDxe clean
and shim.
Min
We have updated the design of AcpiPlatformDxe. Please see the slides in below link.
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.
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review-AcpiPlatformDxe.pptx
Because MailboxAddress in MADT table is determined in runtime in Tdx, so we
separate the update of the MADT table in TdxDxe driver and keep AcpiPlatformDxe clean
and shim.
Thanks
Thanks,
Laszlo
Min
Min Xu <min.m.xu@...>
On 06/22/2021 9:35 PM, Laszlo wrote:
So that the changes in Config-A is not too intrusive.
for example, the ResetVector, Memory Accept in SEC phase, IoMMU/DMA in
DXE phase, and the base IoLib, etc.
Config-A supports the basic Tdx features (except the security features).
Config-B supports the full set of Tdx features.
"OvmfPkgX64.dsc". So as the initial approach, only the basic Tdx features will
be included in Config-A.
"Config-A", so that we will not have a big surprise in the future.
Thanks!
Min
Hi,Yes, in Config-A we chose to follow the standard EDK2 flow (SEC -> PEI -> DXE -> BDS)
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.with existing SEV)
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* Threat model: VMM is NOT out of TCB. (We don't make things worse.)capability. The final binary can run on SEV/TDX/normal OVMF
* The OvmfX64Pkg.dsc includes SEV/TDX/normal OVMF basic boot* No changes to existing OvmfPkgX64 image layout.(so this is "Config-A / Option B", per slide 9 in the v0.9 slide deck)
* 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 that the changes in Config-A is not too intrusive.
Actually Config-A and Config-B share some common (or basic) TDX features,feature TDVF. (Align with existing SEV)
Config-B:
* Add a standalone IntelTdx.dsc to a TDX specific directory for a *full** Threat model: VMM is out of TCB. (We need necessary change toprevent attack from VMM)* IntelTdx.dsc includes TDX/normal OVMF basic boot capability. The finalbinary can run on TDX/normal OVMF* It might eventually merge with AmdSev.dsc, but NOT at this point oftime. 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).
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").
for example, the ResetVector, Memory Accept in SEC phase, IoMMU/DMA in
DXE phase, and the base IoLib, etc.
Config-A supports the basic Tdx features (except the security features).
Config-B supports the full set of Tdx features.
Yes, we will always keep in mind the maintainability and regressions about
- 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.)
"OvmfPkgX64.dsc". So as the initial approach, only the basic Tdx features will
be included in Config-A.
Yes we will submit the patch for Config-B when any particular patch towards
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).
"Config-A", so that we will not have a big surprise in the future.
Thanks!
Min
Laszlo Ersek
On 06/23/21 04:44, Xu, Min M wrote:
4.3.4 AP information reporting from TDVF to OS
from
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf
That section does not go into much detail about the expected MADT
updates / entries.
I've also checked the various MADT subtable types here:
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#interrupt-controller-structure-types
It seems that the TDVF spec speaks about subtable type 0 (Processor
Local APIC):
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#processor-local-apic-structure
I've also checked "acpidump -b; iasl -d" in a normal guest, to remind
myself of the actual MADT contents that QEMU currently generates. I see
minimally the following subtable types:
Subtable Type : 00 [Processor Local APIC]
Subtable Type : 01 [I/O APIC]
Subtable Type : 02 [Interrupt Source Override]
Subtable Type : 04 [Local APIC NMI]
Thus, the TDVF spec creates the extremely unfortunate situation where
subtables of types different from 0 are expected from QEMU, but
subtables of type 0 are expected from the firmware.
In this case, QEMU should likely not populate the MADT with any LAPIC (=
type 0) subtables. Then, Option-3 from slide#5 in [1] (uninstalling the
MADT, *extending* the MADT with LAPIC subtables, installing the new
MADT) seems relatively workable.
(
Note that uninstalling an ACPI table (with EFI_ACPI_TABLE_PROTOCOL)
that was installed by a different driver previously requires the use
of EFI_ACPI_SDT_PROTOCOL. That's because the TableKey parameter taken
by EFI_ACPI_TABLE_PROTOCOL.UninstallAcpiTable() is only available from
EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() -- which the TDX driver
will not have called --, or from EFI_ACPI_SDT_PROTOCOL.GetAcpiTable().
EFI_ACPI_SDT_PROTOCOL.RegisterNotify() also exists, but it should be
avoided. It should not be used to immediately modify or replace the
MADT as soon as the MADT appears. That's because, upon encountering an
error, OvmfPkg/AcpiPlatformDxe rolls back all tables it installed up
to the error. It wouldn't be great if the rollback attempted to remove
a different MADT than what was installed.
)
Another approach (which sounds quite horrible) might be for QEMU to
pre-populate the MADT with just the right *count* of LAPIC subtables,
and then the TDX driver would patch the MADT *in-place* with the proper
LAPIC subtable contents (and then re-checksum the table manually). This
sounds horrible indeed.
Modifying the InstallAcpiTables() function in OvmfPkg/AcpiPlatformDxe,
so that it install a custom NULL protocol when InstallQemuFwCfgTables()
succeeds, seems tolerable. (In order to trigger the TdxDxe driver's MADT
patching.) However, I don't understand the following comment from
slide#5:
about TD_VCPU_INFO_HOB, regarding the information required for filling
in the LAPIC entries in the MADT. But the same HOB should be available
to the TDX DXE driver too.
It would be much better if TDX specific code were added to QEMU that
prevented the generation of the MADT altogether, when running a TDX
guest. Then the firmware would fully own the MADT, and the TDX DXE
driver would only have to wait for the availability of
EFI_ACPI_TABLE_PROTOCOL (simple depex). In this case, of course, the TDX
driver would be responsible for all other subtable types too, not just
type 0 (LAPIC).
If all else fails, you can also copy "OvmfPkg/AcpiPlatformDxe" to
"OvmfPkg/TdxAcpiPlatformDxe", and customize it in any way (e.g. as
described on slides #3 and #4 [1]; Options 1 and 2). In this case,
TdxAcpiPlatformDxe would only be used in "IntelTdx.dsc", not the
pre-existent OvmfPkg*.dsc files.
Summary:
- Options 1 and 2 from [1] are not acceptable for
OvmfPkg/AcpiPlatformDxe.
- Option 3 from [1] is acceptable for OvmfPkg/AcpiPlatformDxe with a
custom NULL protocol instance, but:
- I don't understand the "parameter passing problem".
- How exactly the TdxDxe driver implements the MADT update (or
replacement) remains a question, impacting even QEMU (as QEMU and
TdxDxe must not fight for ownership over the LAPIC subtables). Some
possibilities are:
- stop QEMU from generating the MADT, make TdxDxe own the MADT fully;
- stop QEMU from generating LAPIC subtables;
- make QEMU generate the right number of dummy MADT entries;
- don't touch QEMU, but filter out its LAPIC subtables in TdxDxe.
- Options 1 and 2 from [1] are acceptable for a detached / distinct
driver called "OvmfPkg/TdxAcpiPlatformDxe", but this driver could only
be used in "IntelTdx.dsc".
Thanks
Laszlo
On 06/22/2021 9:35 PM, Laszlo wrote:Thanks, let me mark this with [1].We have updated the design of AcpiPlatformDxe. Please see the slides
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.
in below link.
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review-AcpiPlatformDxe.pptx
I've now read
Because MailboxAddress in MADT table is determined in runtime in Tdx,
so we separate the update of the MADT table in TdxDxe driver and keep
AcpiPlatformDxe clean and shim.
4.3.4 AP information reporting from TDVF to OS
from
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf
That section does not go into much detail about the expected MADT
updates / entries.
I've also checked the various MADT subtable types here:
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#interrupt-controller-structure-types
It seems that the TDVF spec speaks about subtable type 0 (Processor
Local APIC):
https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model/ACPI_Software_Programming_Model.html#processor-local-apic-structure
I've also checked "acpidump -b; iasl -d" in a normal guest, to remind
myself of the actual MADT contents that QEMU currently generates. I see
minimally the following subtable types:
Subtable Type : 00 [Processor Local APIC]
Subtable Type : 01 [I/O APIC]
Subtable Type : 02 [Interrupt Source Override]
Subtable Type : 04 [Local APIC NMI]
Thus, the TDVF spec creates the extremely unfortunate situation where
subtables of types different from 0 are expected from QEMU, but
subtables of type 0 are expected from the firmware.
In this case, QEMU should likely not populate the MADT with any LAPIC (=
type 0) subtables. Then, Option-3 from slide#5 in [1] (uninstalling the
MADT, *extending* the MADT with LAPIC subtables, installing the new
MADT) seems relatively workable.
(
Note that uninstalling an ACPI table (with EFI_ACPI_TABLE_PROTOCOL)
that was installed by a different driver previously requires the use
of EFI_ACPI_SDT_PROTOCOL. That's because the TableKey parameter taken
by EFI_ACPI_TABLE_PROTOCOL.UninstallAcpiTable() is only available from
EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() -- which the TDX driver
will not have called --, or from EFI_ACPI_SDT_PROTOCOL.GetAcpiTable().
EFI_ACPI_SDT_PROTOCOL.RegisterNotify() also exists, but it should be
avoided. It should not be used to immediately modify or replace the
MADT as soon as the MADT appears. That's because, upon encountering an
error, OvmfPkg/AcpiPlatformDxe rolls back all tables it installed up
to the error. It wouldn't be great if the rollback attempted to remove
a different MADT than what was installed.
)
Another approach (which sounds quite horrible) might be for QEMU to
pre-populate the MADT with just the right *count* of LAPIC subtables,
and then the TDX driver would patch the MADT *in-place* with the proper
LAPIC subtable contents (and then re-checksum the table manually). This
sounds horrible indeed.
Modifying the InstallAcpiTables() function in OvmfPkg/AcpiPlatformDxe,
so that it install a custom NULL protocol when InstallQemuFwCfgTables()
succeeds, seems tolerable. (In order to trigger the TdxDxe driver's MADT
patching.) However, I don't understand the following comment from
slide#5:
Open: This method is not practicable if parameters cannot beWhat parameters are we talking about here? The TDVF design guide speaks
transferred when trigger the notify function.
about TD_VCPU_INFO_HOB, regarding the information required for filling
in the LAPIC entries in the MADT. But the same HOB should be available
to the TDX DXE driver too.
It would be much better if TDX specific code were added to QEMU that
prevented the generation of the MADT altogether, when running a TDX
guest. Then the firmware would fully own the MADT, and the TDX DXE
driver would only have to wait for the availability of
EFI_ACPI_TABLE_PROTOCOL (simple depex). In this case, of course, the TDX
driver would be responsible for all other subtable types too, not just
type 0 (LAPIC).
If all else fails, you can also copy "OvmfPkg/AcpiPlatformDxe" to
"OvmfPkg/TdxAcpiPlatformDxe", and customize it in any way (e.g. as
described on slides #3 and #4 [1]; Options 1 and 2). In this case,
TdxAcpiPlatformDxe would only be used in "IntelTdx.dsc", not the
pre-existent OvmfPkg*.dsc files.
Summary:
- Options 1 and 2 from [1] are not acceptable for
OvmfPkg/AcpiPlatformDxe.
- Option 3 from [1] is acceptable for OvmfPkg/AcpiPlatformDxe with a
custom NULL protocol instance, but:
- I don't understand the "parameter passing problem".
- How exactly the TdxDxe driver implements the MADT update (or
replacement) remains a question, impacting even QEMU (as QEMU and
TdxDxe must not fight for ownership over the LAPIC subtables). Some
possibilities are:
- stop QEMU from generating the MADT, make TdxDxe own the MADT fully;
- stop QEMU from generating LAPIC subtables;
- make QEMU generate the right number of dummy MADT entries;
- don't touch QEMU, but filter out its LAPIC subtables in TdxDxe.
- Options 1 and 2 from [1] are acceptable for a detached / distinct
driver called "OvmfPkg/TdxAcpiPlatformDxe", but this driver could only
be used in "IntelTdx.dsc".
Thanks
Laszlo
Min Xu <min.m.xu@...>
On 06/22/2021 9:39 PM, Laszlo wrote:
over-complicated either.
We have updated the design slides to V0.95 and Slides 6-15 are discussing the
Config-A and Config-B.
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review%28v0.95%29.pptx
Your comment is always welcome!
Thanks!
Min
Thanks much for the comments and we don't want to make OvmfPkgX64.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".
over-complicated either.
We have updated the design slides to V0.95 and Slides 6-15 are discussing the
Config-A and Config-B.
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review%28v0.95%29.pptx
Your comment is always welcome!
Thanks!
Min
James Bottomley <jejb@...>
On Thu, 2021-06-24 at 00:24 +0000, Min Xu wrote:
the bugzilla:
https://bugzilla.tianocore.org/show_bug.cgi?id=3429
As well, please?
Thanks,
James
On 06/22/2021 9:39 PM, Laszlo wrote:The mailing list still won't give me that file, can you update it inI should clarify: the relevant part of my preference is not thatThanks much for the comments and we don't want to make OvmfPkgX64.dsc
"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".
over-complicated either.
We have updated the design slides to V0.95 and Slides 6-15 are
discussing the
Config-A and Config-B.
https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review%28v0.95%29.pptx
Your comment is always welcome!
the bugzilla:
https://bugzilla.tianocore.org/show_bug.cgi?id=3429
As well, please?
Thanks,
James