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

[Min Xu]

Thanks much everyone who attended 2 sessions of TDVF design review meeting
and lots of valuable comments and feedbacks received. These 2 meetings were
recorded and now uploaded to below link:
Session 1:
https://drive.google.com/file/d/100__tNVe5erNzExySq2SJOprvBN7zz8u/view?usp=sharing
Session 2:
https://drive.google.com/file/d/1aDvtLhLxzniOISljXwjZH0YT_m7EBn8b/view?usp=sharing

Thank you!
Min


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

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

[Min Xu]

On 06/24/2021 8:36 AM, James Bottomley wrote: 
> On Thu, 2021-06-24 at 00:24 +, Min Xu wrote:
> > On 06/22/2021 9:39 PM, Laszlo wrote:
> > > 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 much for the comments and we don't want to make 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_Rev
> > iew%28v0.95%29.pptx
> > Your comment is always welcome!
> 
> The mailing list still won't give me that file, can you update it in the 
> bugzilla:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> As well, please?
>
Sure. TDVF Design Review v0.95 is uploaded to
https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
Thanks
Min


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

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

[James Bottomley]

On Thu, 2021-06-24 at 00:24 +, Min Xu wrote:
> On 06/22/2021 9:39 PM, Laszlo wrote:
> > 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 much for the comments and we don't want to make 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 mailing list still won't give me that file, can you update it in
the bugzilla:

https://bugzilla.tianocore.org/show_bug.cgi?id=3429

As well, please?

Thanks,

James





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

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

[Min Xu]

On 06/22/2021 9:39 PM, Laszlo wrote:
> 
> 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 much for the comments and we don't want to make 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



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

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

[Laszlo Ersek]

On 06/23/21 04:44, Xu, Min M wrote:
> On 06/22/2021 9:35 PM, Laszlo wrote:
>>
>> 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.
>>
> We have updated the design of AcpiPlatformDxe. Please see the slides
> in below link.
> https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review-AcpiPlatformDxe.pptx

Thanks, let me mark this with [1].

>
> 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.

I've now read

  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 be
> transferred when trigger the notify function.

What parameters are we talking about here? The TDVF design guide speaks
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
  

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

[Min Xu]

On 06/22/2021 9:35 PM, Laszlo 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)
>
Yes,  in Config-A we chose to follow the standard EDK2 flow (SEC -> PEI -> DXE 
-> BDS)
So that the changes in Config-A is not too intrusive.
>
> 
> >
> >
> >
> > 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).
> 
> 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").
> 
Actually Config-A and Config-B share some common (or basic) TDX features,
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.
>
> 
> - 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.)
>
Yes, we will always keep in mind the maintainability and regressions about
"OvmfPkgX64.dsc". So as the initial approach, only the basic Tdx features will
be included in Config-A.
>
> 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).
>
Yes we will submit the patch for Config-B when any particular patch towards
"Config-A", so that we will not have a big surprise in the future.
>

Thanks!
Min


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

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

[Min Xu]

On 06/22/2021 9:35 PM, Laszlo wrote: 
> 
> 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.
> 
We have updated the design of AcpiPlatformDxe. Please see the slides in below 
link.
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,
> Laszlo
> 
Thanks
Min


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

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

[Laszlo Ersek]

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  On Behalf Of Min Xu
>> Sent: Friday, June 11, 2021 6:30 AM

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

[Laszlo Ersek]

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).

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  On Behalf Of Min Xu
> Sent: Friday, June 11, 2021 6:30 AM
> To: devel@edk2.groups.io; Yao, Jiewen ; 
> r...@edk2.groups.io
> Cc: j...@linux.ibm.com; Laszlo Ersek ; Brijesh Singh 
> ; Tom Lendacky ; 
> erdemak...@google.com; c...@microsoft.com; bret.barke...@microsoft.com; Jon 
> Lange ; Karen Noel ; Paolo Bonzini 
> ; Nathaniel McCallum ; Dr. David 
> Alan Gilbert ; Ademar de Souza Reis Jr. 
> 
> 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

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

[Min 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  On Behalf Of Min Xu
Sent: Friday, June 11, 2021 6:30 AM
To: devel@edk2.groups.io; Yao, Jiewen ; 
r...@edk2.groups.io
Cc: j...@linux.ibm.com; Laszlo Ersek ; Brijesh Singh 
; Tom Lendacky ; 
erdemak...@google.com; c...@microsoft.com; bret.barke...@microsoft.com; Jon 
Lange ; Karen Noel ; Paolo Bonzini 
; Nathaniel McCallum ; Dr. David 
Alan Gilbert ; Ademar de Souza Reis Jr. 
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> 
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 
mailto:ler...@redhat.com>>; Brijesh Singh 
mailto:brijesh.si...@amd.com>>; Tom Lendacky 
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 
mailto:jla...@microsoft.com>>; Karen Noel 
mailto:kn...@redhat.com>>; Paolo Bonzini 
mailto:pbonz...@redhat.com>>; Nathaniel McCallum 
mailto:npmccal...@redhat.com>>; Dr. David Alan Gilbert 
mailto:dgilb...@redhat.com>>; Ademar de Souza Reis Jr. 
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 (#76367): https://edk2.groups.io/g/devel/message/76367
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[James Bottomley]

On Thu, 2021-06-10 at 21:38 -0400, James Bottomley wrote:
> On Fri, 2021-06-11 at 01:36 +, Yao, Jiewen wrote:
> > 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
> > )
> 
> Apparently it's not possible to join from a web browser: is there a
> dial in?

In the absence of a dial in, I'll view the recording.  I did most of my
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




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

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

[James Bottomley]

On Fri, 2021-06-11 at 01:36 +, Yao, Jiewen wrote:
> 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
> )

Apparently it's not possible to join from a web browser: is there a
dial in?

James




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

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

[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

te...@conf.intel.com

Video Conference ID: 119 715 416 0

[Alternate VTC dialing 
instructions](https://conf.intel.com/teams/?conf=1197154160=teams=conf.intel.com=test_call)

[Learn More](https://aka.ms/JoinTeamsMeeting) | [Meeting 
options](https://teams.microsoft.com/meetingOptions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19=46c98d88-e344-4ed4-8496-4ed7712e255d=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkLWI5NDgtYTFmYjNkOWI0ZDg4@thread.v2=0=en-US)

==





> -Original Message-
> From: James Bottomley 
> Sent: Friday, June 11, 2021 9:33 AM
> To: Xu, Min M ; devel@edk2.groups.io; Yao, Jiewen
> ; r...@edk2.groups.io
> Cc: Laszlo Ersek ; Brijesh Singh ;
> Tom Lendacky ; erdemak...@google.com;
> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
> ; Karen Noel ; Paolo Bonzini
> ; Nathaniel McCallum ; Dr.
> David Alan Gilbert ; Ademar de Souza Reis Jr.
> 
> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
> 
> On Thu, 2021-06-10 at 22:30 +, Xu, Min M wrote:
> > 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
> 
> What's the url of the meeting?  Apparently it isn't in the calendar
> entry.
> 
> James
> 



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


BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Repeat:35889
UID:ccyo.1615368347866508187.a...@groups.io
DTSTAMP:20210607T062928Z
ORGANIZER;CN=Ray Ni:mailto:ray...@intel.com
DTSTART;TZID=Asia/Shanghai:20210319T093000
DTEND;TZID=Asia/Shanghai:20210319T103000
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=FR
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:## TOPIC\n\n1. NA\n\nFor more info\, see here: https://www.ti
 anocore.org/design-meeting/\n\n---\n## Microsoft Teams meeting\n\n### Joi
 n on your computer or mobile app\n\n[Click here to join the meeting](http
 s://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZT
 dkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d
 88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc2
 7-3d06c576cc19%22%7d)\n\n### Join with a video conferencing device\n\ntea
 m...@conf.intel.com\n\nVideo Conference ID: 119 715 416 0\n\n[Alternate VTC
  dialing instructions](https://conf.intel.com/teams/?conf=1197154160=
 teams=conf.intel.com=test_call)\n\n[Learn More](https://aka.ms/Joi
 nTeamsMeeting) | [Meeting options](https://teams.microsoft.com/meetingOpt
 ions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19=46c98d88-
 e344-4ed4-8496-4ed7712e255d=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkL
 WI5NDgtYTFmYjNkOWI0ZDg4@thread.v2=0=en-US)
LOCATION:Microsoft Teams
SEQUENCE:0
EXDATE:20210402T013000Z
EXDATE:20210416T013000Z
EXDATE:20210430T013000Z
EXDATE:20210514T013000Z
END:VEVENT
BEGIN:VEVENT
X-GIOIDS:Event:1092883 
UID:1092883.ccyo.1615368347866508187.a...@groups.io
DTSTAMP:20210607T062928Z
ORGANIZER;CN=Ray Ni:mailto:ray...@intel.com
DTSTART:20210319T013000Z
DTEND:20210319T023000Z
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:## TOPIC\n\n1. [New EFI Protocols for EDK2 Redfish \nImplemen
 tation V2](https://edk2.groups.io/g/devel/files/Designs/2021/0319/New%20E
 FI%20Protocols%20for%20edk2%20Redfish%20Implementation_v2.pdf) (Nickl

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

[James Bottomley]

On Thu, 2021-06-10 at 22:30 +, Xu, Min M wrote:
> 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

What's the url of the meeting?  Apparently it isn't in the calendar
entry.

James




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

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

[Min 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  On Behalf Of Yao, Jiewen
Sent: Thursday, June 3, 2021 9:51 PM
To: r...@edk2.groups.io; devel@edk2.groups.io
Cc: j...@linux.ibm.com; Laszlo Ersek ; Brijesh Singh 
; Tom Lendacky ; 
erdemak...@google.com; c...@microsoft.com; bret.barke...@microsoft.com; Jon 
Lange ; Karen Noel ; Paolo Bonzini 
; Nathaniel McCallum ; Dr. David 
Alan Gilbert ; Ademar de Souza Reis Jr. 
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 (#76340): https://edk2.groups.io/g/devel/message/76340
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Erdem Aktas via groups.io]

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  wrote:

> My point is that the "one binary" that the slide deck refers to (i.e.,
> 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.

This is what we are asking as a single binary.

> But "OvmfPkgX64.dsc" is *not* the "one binary" that is suitable for
> 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.

This is okay for us.

> (10) This slide (slide 11) basically describes an intrusive
> 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.

Embedding secure keys might be a good idea to remove the VMM from the
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 a
> 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.

I think there is a confusion in slide #13. I agree that the GUIDed
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 OVMF
> 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.
>

I am guessing what Intel refers to is "SEV-ES resetblock" which sets
the AP reset vector (jump address) address.

> (22) EmuVariableFvbRuntimeDxe
>
> 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

Copying configuration variables into configuration volume is "good"
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  

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

[James Bottomley]

On Wed, 2021-06-09 at 17:47 +0200, Paolo Bonzini wrote:
> On 09/06/21 16:28, James Bottomley wrote:
> > That would cut across the ApEntrypoint and the guidedStructureEnd.
> > 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.
> 
> Isn't the initial state included in the save area just like for SEV-
> ES?

Initial state of what?  We currently have two entries: one points to
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 builds
> the encrypted image, that needs to understand that GUIDed structure.

Yes, it's really to make the configuration of the OVMF blob somewhat
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 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.

Well, exactly ... depending on what the requirement is we can do pretty
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




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

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

[Paolo Bonzini]

On 09/06/21 16:28, James Bottomley wrote:

That would cut across the ApEntrypoint and the guidedStructureEnd.
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.


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.


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



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

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

[James Bottomley]

On Wed, 2021-06-09 at 13:00 +0200, Laszlo Ersek wrote:
> On 06/09/21 02:58, Xu, Min M wrote:
> > On 06/09/2021 3:33 AM, Laszlo wrote:
> > > On 06/08/21 18:01, James Bottomley wrote:
> > > > 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 think I made the same comment, in different words. (Point (12)
> > > at
> > >  > > June/msg00143.html>.)
> > > 
> > So my understanding to this solution is that: 
> > 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?
> 
> This is my understanding, yes; James will know more details though.

Pretty much, yes.  The guided structure is designed as a backwards
table, so you can tell if it's present or not by looking for the table
guid (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffd0.  If you find
that, it gives you the size of the table as the u16 preceding the GUID.
All entries are of the form

  

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




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

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

[James Bottomley]

On Wed, 2021-06-09 at 02:01 +, Xu, Min M wrote:
> On 06/09/2021 12:01 AM, James Bottomley wrote:
[...]
> > 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 0xfff0, 
> protected-mode goes to 0xffe0, 
> long-mode goes to 0xffd0. 

That would cut across the ApEntrypoint and the guidedStructureEnd. 
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





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

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

[Laszlo Ersek]

On 06/09/21 02:58, Xu, Min M wrote:
> On 06/09/2021 3:33 AM, Laszlo wrote:
>> On 06/08/21 18:01, James Bottomley wrote:

>>> 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 think I made the same comment, in different words. (Point (12) at
>> > June/msg00143.html>.)
>>
> So my understanding to this solution is that: 
> 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?

This is my understanding, yes; James will know more details though.

[...]

Thanks,
Laszlo



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

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

[Min Xu]

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 0xfff0, 
protected-mode goes to 0xffe0, 
long-mode goes to 0xffd0. 

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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Min Xu]

On 06/09/2021 3:33 AM, Laszlo wrote:
> (Min Xu got dropped from the CC list for some reason, at *some* point in this
> sub-thread! Not sure when. Re-adding him.)
> 
> Commenting on excerpts:
> 
> On 06/08/21 18:01, James Bottomley wrote:
> 
> > 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?
> 
> Great idea, in my opinion.
> 
Agree, it's 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 think I made the same comment, in different words. (Point (12) at
>  June/msg00143.html>.)
> 
So my understanding to this solution is that: 
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?

> 
> > 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?
>
> What's more, we should use a dedicated ResetVector (through a DSC+FDF
> dedicated solely to TDX).
> 
If TDVF has a separate DSC/FDF, then this is not a problem. Let's wait for a
conclusion to the *one binary* solution.
Thanks for your suggestion.
> 
> > 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?
> 
> I believe I made the same comment in point (20) (see URL above).
> 
I will answer this comments in my later response. Thanks.
> 
> > Slide 41: IOMMU operation.
> 
> That's more like slides 40 and 42, no?
> 
> 
> > The implication is that you only transition to unencrypted memory for
> > DMA during the actual operation,
> 
> Yes, this is the idea behind EDKII_IOMMU_PROTOCOL, which
> OvmfPkg/IoMmuDxe implements (for SEV only, currently).
> 
> 
> > 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?
> 
> Effectively, yes. (Your summary corresponds to a BusMasterRead
> operation.)
> 
In TDX there are the concepts of Private-Memory and Shared-Memory. 
By default the memory are private. Before the DMA operation, the private
memory should be converted to Shared-Memory by setting the S-Bit. Then
VMM and Guest can do the DMA operation.
(The difference is that in TDX even the Shared-Memory is encrypted with 
a shared-key between VMM and Guest. So we call it Shared-Memory)
So all the changes in IOMMU by TDX is just to customize the page 
decryption / encryption primitives in the driver , and the general logic will 
not
be touched.
> 
> > Given that SEV operates quite happily with always in the clear DMA
> > buffers,
> 
> I don't understand this comment -- is it a statement about SEV as a 
> technology,
> or about OvmfPkg/IoMmuDxe?
> 
> Specifically in the context of OvmfPkg/IoMmuDxe, there is no "always-in-the-
> clear DMA".
> 
> EDKII_IOMMU_PROTOCOL was designed to fit cleanly into the Map(), Unmap(),
> AllocateBuffer(), FreeBuffer() terminology of the UEFI standard
> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL. As far as I
> can tell, the original use case for EDKII_IOMMU_PROTOCOL was VT-d on bare
> metal, but the protocol proved a good match for SEV too.
> 
> VIRTIO_DEVICE_PROTOCOL has similar member functions
> (AllocateSharedPages, FreeSharedPages, MapSharedBuffer,
> UnmapSharedBuffer).
> 
> As long as a PCI device driver (or virtio driver) uses these member functions
> judiciously, only "BusMasterCommonBuffer" operations will be backed by long-
> term plaintext (decrypted) pages. One-shot read and write transactions will be
> backed by plaintext (decrypted) pages only as long as necessary.
> 
> The transitions you outline already happen in any plain SEV guest that uses 
> PCI
> DMA or virtio.
> 
> 
> > this seems to have the potential to be a performance problem, but what
> > security does it gain?
>
As I mentioned above, in TDX DMA operation even the Shared-Memory is encrypted
by a shared-key between VMM and Guest. It is not *plain-text* outside VMM
>
> We have not experienced performance problems due to this kind of IOMMU
> protocol usage, when booting SEV guests.
> 
In our test, we don't see the performance problem when booting TDX guests.
We do have the performance issue in "Accept 

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

[Laszlo Ersek]

(Min Xu got dropped from the CC list for some reason, at *some* point in
this sub-thread! Not sure when. Re-adding him.)

Commenting on excerpts:

On 06/08/21 18:01, James Bottomley wrote:

> 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?

Great idea, in my opinion.


> 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 think I made the same comment, in different words. (Point (12) at
.)


> 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?

What's more, we should use a dedicated ResetVector (through a DSC+FDF
dedicated solely to TDX).


> 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?

I believe I made the same comment in point (20) (see URL above).


> Slide 41: IOMMU operation.

That's more like slides 40 and 42, no?


> The implication is that you only transition to unencrypted memory for
> DMA during the actual operation,

Yes, this is the idea behind EDKII_IOMMU_PROTOCOL, which
OvmfPkg/IoMmuDxe implements (for SEV only, currently).


> 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?

Effectively, yes. (Your summary corresponds to a BusMasterRead
operation.)


> Given that SEV operates quite happily with always in the clear DMA
> buffers,

I don't understand this comment -- is it a statement about SEV as a
technology, or about OvmfPkg/IoMmuDxe?

Specifically in the context of OvmfPkg/IoMmuDxe, there is no
"always-in-the-clear DMA".

EDKII_IOMMU_PROTOCOL was designed to fit cleanly into the Map(),
Unmap(), AllocateBuffer(), FreeBuffer() terminology of the UEFI standard
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL. As far as I can
tell, the original use case for EDKII_IOMMU_PROTOCOL was VT-d on bare
metal, but the protocol proved a good match for SEV too.

VIRTIO_DEVICE_PROTOCOL has similar member functions
(AllocateSharedPages, FreeSharedPages, MapSharedBuffer,
UnmapSharedBuffer).

As long as a PCI device driver (or virtio driver) uses these member
functions judiciously, only "BusMasterCommonBuffer" operations will be
backed by long-term plaintext (decrypted) pages. One-shot read and write
transactions will be backed by plaintext (decrypted) pages only as long
as necessary.

The transitions you outline already happen in any plain SEV guest that
uses PCI DMA or virtio.


> this seems to have the potential to be a performance problem, but what
> security does it gain?

We have not experienced performance problems due to this kind of IOMMU
protocol usage, when booting SEV guests.

The basic goal was to keep everything as tightly encrypted as possible
(as permitted by the individual PCI or Virtio driver, through its
conservative usage of BusMasterCommonBuffer operations).

I won't claim that it has zero performance impact, but we should
remember the purpose that firmware serves (namely, "booting an operating
system"). Really -- I don't recall any performance issues. This applies
to such virtio devices & drivers too that aren't "bootable", such as
virtio-gpu-pci (VirtioGpuDxe) and virtio-rng-pci (VirtioRngDxe).

(

  If you enable verbose logs, OvmfPkg/IoMmuDxe does produce an immense
  amount of messages (with the express purpose of a human reading
  through them, and matching up decryption and re-encryption actions --
  I've done it, likely with some ad-hoc scripts). *This* does slow down
  the boot considerably (if you actually enable the QEMU debug console),
  but for a different reason: producing debug logs through the QEMU
  debug console (IO Port) is very-very costly in a SEV guest. Not just
  because an IO port trap may be more expensive in a SEV guest, but
  because SEV does not support REP OUTSB, so every debug character
  written traps separately, as opposed to every line written. See
  the following commits:

  - b6d11d7c4678 ("MdePkg: BaseIoLibIntrinsic (IoLib class) library",
2017-04-13),

  - 97353a9c914d ("OvmfPkg: Update dsc to use IoLib from
BaseIoLibIntrinsicSev.inf", 2017-07-10),

  - 98a4d04e8fda ("MdePkg/BaseIoLibIntrinsic: fix SEV (=unrolled)
variants of IoWriteFifoXX()", 2017-09-11),

  - c09d9571300a ("OvmfPkg: save on I/O port accesses when 

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

[James Bottomley]

On Thu, 2021-06-03 at 13:51 +, Yao, Jiewen wrote:
> 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

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.

> You can have an offline review first. You comments will be warmly
> welcomed and we will continuously update the slides based on the
> feedbacks.

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?

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




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

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

[Laszlo Ersek]

On 06/08/21 14:27, Xu, Min M wrote:
> On 06/04/2021 12:12 AM, Laszlo wrote:

>> But it counts as an absolute disaster nowadays, and should not be revived in
>> any platform. If you don't have pflash in TDX guests, just accept that you
>> won't have non-volatile variables. And link PlatformFvbLibNull into
>> EmuVariableFvbRuntimeDxe. You're going to need a separate
>> PlatformBootManagerLib instance anyway.
>>
> I have a question here, that if PlatformFvbLibNull is linked into 
> EmuVaiableFvRuntimeDxe,
> Does it mean it cannot write to the in-RAM variable store?

No, that's not the case; PlatformFvbLibNull only turns the hooks
(special callbacks) into no-ops; the normal operation of
EmuVariableFvbRuntimeDxe is not disrupted.

The APIs in the PlatformFvbLib class are PlatformFvbDataRead,
PlatformFvbDataWritten, PlatformFvbBlocksErased; they are called at the
ends of the functions FvbProtocolEraseBlocks(), FvbProtocolWrite(),
FvbProtocolRead(), in "OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c". If the
PlatformFvb* APIs do nothing, that's not a problem for
EmuVariableFvbRuntimeDxe.

(In fact, even in the non-Null instance -- that is, in the
EmuVariableFvbLib instance --, the read and erase callbacks are empty;
and the write callback only signals an event, at best.)

>> (We should have removed EmuVariableFvbRuntimeDxe a long time ago from
>> the traditional OVMF platforms, i.e. made pflash a hard requirement, even
>> when SMM is not built into the platform -- but whenever I tried that, Jordan
>> always shot me down.)
>>
> I am afraid in TDVF we have to use EmuVariableFvRuntimeDxe to emulate the
> in-RAM, as I explained pflash is not part of the *board* in TDX setup.

Using EmuVariableFvbRuntimeDxe in the TDVF platform is fine (with the
Null hooks, see above), as long as we carefully document the expected /
resultant behavior of the UEFI variable services.

(This is not a comment on my part on the SB situation, which remains an
open question for TDVF, for the time being.)

Thanks
Laszlo



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

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

[Min Xu]

On 06/04/2021 12:12 AM, Laszlo wrote:

> (22) EmuVariableFvbRuntimeDxe
> 
> 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
> 
>   OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> 
> into the firmware platform is useless, as it is mutually exclusive with
> 
>   OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
> 
> (via dynamic means -- a dynamic PCD).
> 
> Note that the FDF file places QemuFlashFvbServicesRuntimeDxe in APRIORI
> DXE when SMM_REQUIRE is FALSE. This driver checks for pflash presence,
> and lets EmuVariableFvbRuntimeDxe perform its in-RAM flash emulation
> only in case pflash is not found.
> 
Right, pflash is not part of the *board* in any TDX setup.
This is a limitation from the Qemu (the tdx-qemu) side. TDVF is copied into
RAM. Generic loader is the one for it.
In this case (pflash is not found), FvbServiceRuntimeDxe.inf will return
EFI_WRITE_PROTECTED in its FvbInitialize().
EmuVariableFvbRuntimeDxe will then perform its in-RAM flash emulation.

> So this is again in favor of a separate platform -- if we know pflash is never
> part of the board, then QemuFlashFvbServicesRuntimeDxe is never needed,
> but you cannot remove it from the traditional DSC/FDF files.
> 
Yes, if TDVF is a separate DSD/FDF, QemuFlashFvbServicesRuntimeDxe will be
removed from the image.

> Second, EmuVariableFvbRuntimeDxe consumes the PlatformFvbLib class, for
> the PlatformFvbDataWritten() API (among other things). This lib class is
> implemented by two instances in OvmfPkg, PlatformFvbLibNull and
> EmuVariableFvbLib. The latter instance allows Platform BDS to hook an event
> (for signaling) via "PcdEmuVariableEvent" into the
> EmuVariableFvbRuntimeDxe driver.
> 
> In old (very old) QEMU board configurations, namely those without pflash,
> this (mis)feature is used by OVMF's PlatformBootManagerLib to write out all
> variables to the EFI system partition in a regular file called \NvVars, with 
> the
> help of NvVarsFileLib, whenever EmuVariableFvbRuntimeDxe writes out an
> emulated "flash" block. For this purpose, the traditional OVMF DSC files link
> EmuVariableFvbLib into EmuVariableFvbRuntimeDxe.
> 
Thanks for the explanation. It's very helpful for me to understand the code.

> But it counts as an absolute disaster nowadays, and should not be revived in
> any platform. If you don't have pflash in TDX guests, just accept that you
> won't have non-volatile variables. And link PlatformFvbLibNull into
> EmuVariableFvbRuntimeDxe. You're going to need a separate
> PlatformBootManagerLib instance anyway.
>
I have a question here, that if PlatformFvbLibNull is linked into 
EmuVaiableFvRuntimeDxe,
Does it mean it cannot write to the in-RAM variable store?

> 
> (We should have removed EmuVariableFvbRuntimeDxe a long time ago from
> the traditional OVMF platforms, i.e. made pflash a hard requirement, even
> when SMM is not built into the platform -- but whenever I tried that, Jordan
> always shot me down.)
>
I am afraid in TDVF we have to use EmuVariableFvRuntimeDxe to emulate the
in-RAM, as I explained pflash is not part of the *board* in TDX setup.
In the traditional EmuVariableFvRuntimeDxe, the FV contents will be initialized.
But TDVF has its own requirement, that the SB keys in CFV need to be copied
into the FV contents. That's why EmuVariableFvRuntimeDxe is updated in
TDVF project.

> 
> My point is: using EmuVariableFvbRuntimeDxe in the TDX platform may be
> defensible per se, but we must be very clear that it will never provide a
> standards-conformant service for non-volatile UEFI variables, and we must
> keep as much of the \NvVars mess out of EmuVariableFvbRuntimeDxe as
> possible. This will require a separate PlatformBootManagerLib instance for
> TDX anyway (or maybe share PlatformBootManagerLibGrub with
> "OvmfPkg/AmdSev/AmdSevX64.dsc").
> 
> Apart from the volatility aspect, let's assume we have this in-RAM emulated
> "flash device", storing authenticated UEFI variables for Secure Boot purposes.
> And we don't have SMM.
> 
> What protects this in-RAM variable store from tampering by the guest OS?
> It's all guest RAM only, after all. What provides the privilege barrier 
> between
> the guest firmware and the guest OS?
A good question and we will answer it a bit later. Thanks for your patience.

> Thanks
> Laszlo


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

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

[Laszlo Ersek]

On 06/06/21 14:49, Xu, Min M wrote:
> On June 6, 2021 7:30 PM, Michael Brown Wrote:
>> On 06/06/2021 03:03, Min Xu wrote:
 (11) "Page table should support both 4-level and 5-level page table"

 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.

>>> Yes, 5-level paging is a strict requirement for TDX. I would wait for
>>> the conclusion of the *one binary*.
>>
>> The "one binary" decision isn't relevant here, is it?  It would make more
>> 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.
>>
> 
> In our first version of TDVF, a static 5-level page table is used. It is 
> simple and
> 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.

My primary concern with the 5-level paging is not that the core
infrastructure is absent from edk2 -- it is present alright. (Over time,
numerous issues have been found and fixed in it, but that's kind of
expected, with such a big feature.) I understand it has been in use
successfully on a number of physical platforms.

My problem is that, AFAICT, the 5-level paging infrastructure of edk2
has never been *tested* on QEMU/KVM, as a part of OVMF. I have
absolutely no idea what to expect.

The "one binary" decision is a little bit relevant:

- If 5-level paging blows up on QEMU/KVM, as a part of OVMF, then
restricting the breakage (possibly a regression even?) to the new TDX
platform is good.

- On the other hand, both 5-level paging and TDX are complex in their
own rights; developing feature sets in small isolated waves is always
best. There are going to be "bug hunts" in the TDX platform of course;
finding an *orthogonal* 5-level paging bug (anywhere in the virt stack,
for that matter) is not the greatest outcome for a supposed TDX bug hunt.

- I figure users might want 5-level paging for OVMF at some point
anyway, even without TDX.

The last two points (especially the middle point of the three) kind of
outweigh(s) the first point for me.

Thanks
Laszlo



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

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

[Min Xu]

On June 6, 2021 7:30 PM, Michael Brown Wrote:
> On 06/06/2021 03:03, Min Xu wrote:
> >> (11) "Page table should support both 4-level and 5-level page table"
> >>
> >> 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.
> >>
> > Yes, 5-level paging is a strict requirement for TDX. I would wait for
> > the conclusion of the *one binary*.
> 
> The "one binary" decision isn't relevant here, is it?  It would make more
> 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.
> 

In our first version of TDVF, a static 5-level page table is used. It is simple 
and
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


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

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

[Michael Brown]

On 06/06/2021 09:52, Min Xu wrote:

On June 4, 2021 12:12 AM, Laszlo wrote:

(18) says "SMM is not supported in Td guest" -- how is the variable store
protected from direct hardware (pflash) access from the guest OS?
Without SMM, the guest OS need not go through gRT->SetVariable() to
update authenticated non-volatile UEFI variables, and that undermines
Secure Boot.


Let me explain the SMM and Secure boot in TDX like below:
1) TDX doesn't support virtual SMM in guest. Virtual SMI cannot be injected
  into TD guest.
2) SMI/SMM is used to manage variable update to avoid expose Flash direct.
 So SMM is not must-to-have for secure boot, but help to mitigate the 
security risk.
3) We don't trust VMM. That is why we need TDX.
4) If you trust VMM to emulate SMM, then you don't need TDX.


Secure Boot defines a security boundary between the firmware and the 
operating system: the operating system is not permitted to make 
arbitrary changes to firmware variables.


It sounds as though you have decided that the TDX security properties 
remove the need for the Secure Boot security properties.  That would be 
a viable conclusion: if the user is able to verify that the intended 
workload is running in the VM (and the VM is disposable anyway) then 
there is not much value added by also having Secure Boot.


However, it's not valid to pretend to also include Secure Boot, knowing 
that there is no way to actually provide the security properties of 
Secure Boot.


If TDX can't support SMM (or some equivalent way for the guest 
*firmware* to guarantee that the ring 0 guest OS cannot make arbitrary 
changes to UEFI variables), then TDX cannot support Secure Boot.


Thanks,

Michael


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

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

[Michael Brown]

On 06/06/2021 03:03, Min Xu wrote:
(11) "Page table should support both 4-level and 5-level page 
table"


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.



Yes, 5-level paging is a strict requirement for TDX. I would wait for
the conclusion of the *one binary*.


The "one binary" decision isn't relevant here, is it?  It would make
more 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.

Michael


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

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

[Min Xu]

On June 4, 2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > 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.
> 
> Resending my earlier comments in this mailing list thread, with the feedback
> inserted at the proper spots that has been given in the off-list thread since
> then:
> 

Continue my comments from here.

> *** Slide 35-36: DXE phase
> 
> (16) "Some DXE Drivers not allowed to load/start in Td guest -- Network
> stack, RNG, ..."
> 
> Same comment as (several times) above. The Linuxboot project is a good
> example for eliminating cruft from DXEFV (in fact, for eliminating most of the
> DXE phase). In a TDX environment, why include drivers in the firmware binary
> that are never used? Meanwhile, DXEFV in OVMF grows by a MB every 1.5
> years or so. Again, remove these drivers from the DSC/FDF then, and it needs
> to be a separate platform.
> 
It is because of the *one binary* so that we have to include all the drivers in 
the
firmware binary. Some of the DXE drivers are not called in TDX, but they're 
dispatched
in Non-Tdx environment.
I will explain more about this topic in next version of design slides.
Also I would wait for the conclusion to the *one binary*.

> (17) "Other DXE Phase drivers -- [...] AcpiPlatformDxe"
> 
> I'm not sure what this section is supposed to mean. Other DXE phase drivers
> included, or excluded? Without AcpiPlatformDxe, the guest OS will not see
> QEMU's ACPI content, and will almost certainly malfunction.
> 
Sorry for the confusion about the title. This slides means Other DXE phase 
drivers
including AcpiPlatformDxe is included. I will update the slides to be more clear
and accurate.

> ... Back from slide 48: ignore this for now, I'll comment in more detail 
> later.
> 
> 
> *** Slide 37: DXE Core
> 
> (18) says "SMM is not supported in Td guest" -- how is the variable store
> protected from direct hardware (pflash) access from the guest OS?
> Without SMM, the guest OS need not go through gRT->SetVariable() to
> update authenticated non-volatile UEFI variables, and that undermines
> Secure Boot.
> 
Let me explain the SMM and Secure boot in TDX like below:
1) TDX doesn't support virtual SMM in guest. Virtual SMI cannot be injected
 into TD guest.
2) SMI/SMM is used to manage variable update to avoid expose Flash direct.
So SMM is not must-to-have for secure boot, but help to mitigate the 
security risk.
3) We don't trust VMM. That is why we need TDX. 
4) If you trust VMM to emulate SMM, then you don't need TDX.

> Note that, while SEV-ES has the same limitation wrt. SMM, the
> "OvmfPkg/AmdSev/AmdSevX64.dsc" platform doesn't even include the
> Secure Boot firmware feature. For another example, the OVMF firmware
> binary in RHEL that's going to support SEV-ES is such a build of
> "OvmfPkgX64.dsc"
> that does not include the Secure Boot feature either.
> 
> But in this TDX slide deck, Secure Boot certificates are embedded in the CFV
> (configuration firmware volume) -- see slide 11 and slide 16 --, which
> suggests that this platform does want secure boot.
> 
Yes, TDVF does support Secure Boot.

> ... Back from slide 48: I'm going to make *additional* comments on this,
> when I'm at slide 48, too.
> 
> The rest of this slide (slide 37) looks reasonable (generic DXE Core changes 
> --
> possibly PI spec changes too).
Yes, there is new attribute (EFI_RESOURCE_ATTRIBUTE_ENCRYPTED) in PiHob.h

> 
> 
> *** Slides 38 through 39:
> 
> These seem reasonable (TdxDxe assumes some responsibilities of
> OvmfPkg/PlatformPei)
> 
> 
> *** Slides 40 through 42:
> 
> *If* you really can implement TDX support for the IOMMU driver *this*
> surgically, then I'm OK with it. The general logic in the IOMMU driver was
> truly difficult to write, and I'd be seriously concerned if those parts would
> have to be modified. Customizing just the page encryption/decryption
> primitives for TDX vs. SEV is OK.
Actually all the changes we do in IOMMU is to customize the page encryption 
/ decryption primitive for TDX and SEV. We will probe the Td or Non-Td in
run-time, then the corresponding APIs will be called.
 
> 
> 
> *** Slides 43 through 47:
> 
> (19) Slide 46 and slide 47 are almost identical. Please consolidate them into 
> a
> single slide.
> 
Slide 46 is of Td measurement, like TpmMeasurement. 
SecurityPkg/Library/DxeTpmMeasurementLib
Slide 47 is of Measure boot. 
SecurityPkg/Library/DxeTpm2MeasureBootLib
I will refine the two slides to make it more clear. Thanks for reminder.

> (20) the TPM2 infrastructure in edk2 is baroque 

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

[Min Xu]

On June 4, 2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > 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.
> 
> Resending my earlier comments in this mailing list thread, with the feedback
> inserted at the proper spots that has been given in the off-list thread since
> then:
> 

Continue my comments from here.

> 

> *** Slide 11 -- TDVF Image (1)
> 
> (9) CFV -- Configuration Firmware Volume (VarStore.fdf.inc), containing SB
> keys -- how is this firmware volume populated (at build time)? Is this a
> hexdump?
> 
CFV is populated in post build. We can provide such python scripts to do the
SB keys enrollment.

> ... Back from slide 16: it seems like CFV is a raw hexdump indeed; how is that
> managed when keys change (at build time)?
> 
As I mentioned above, SB keys are enrolled in post build phase. We can provide
a python scripts to add/delete/append the keys.

> (10) This slide (slide 11) basically describes an intrusive 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).
Actually in our first version of TDVF, it is a separated dsc/fdf. But when I 
try to
implement the *one binary*, I have to figure out some way to put our 
mailbox/tdhob.
I checked the OvmfPkgX64.fdf and mimics what SEV-ES does in MEMFD.
I would wait for a conclusion of the *one binary* and then figure out how to
handle the mailbox/tdhob.
> 
> 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.

As I mentioned above, the SB keys are enrolled in post-build. The standard build
script:
  build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC5
Its output is a standard OVMF image (with a clean CFV/VarStore)
If the customers want the SB feature configured, it's up to them to enroll the 
SB
keys. 
CFV is just a concept in TDVF. From the perspective of Standard OVMF, it is 
still
the VarStore.

> 
> Edk2 (and PI and UEFI) are definitely flexible enough for accommodating TDX,
> but the existent, traditional OVMF platforms are a bad fit. In my opinion.
> 
> 
> *** Slide 12: TDVF Image (2)
> 
> (11) "Page table should support both 4-level and 5-level page table"
> 
> 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.
> 
Yes, 5-level paging is a strict requirement for TDX. 
I would wait for the conclusion of the *one binary*.
> 
> *** Slide 13:
> 
> (12) My comment is that the GUID-ed structure chain already starts at a 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.
Yes, we prefer a TDX GUID in ResetVector. In that GUID there is a offset which
points to the actual TDX Metadata blob.
> 
> (13) Regarding "4G-0x20[0x10] is OVMF AP reset vector (used in OVMF
> 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.
> 
Thanks Laszlo for explanation. 
> 
> *** Slides 14 through 16:
> 
> I consider these TDVF firmware image 

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

[James Bottomley]

On Fri, 2021-06-04 at 15:52 +0100, Michael Brown wrote:
> On 04/06/2021 11:43, Michael Brown wrote:
> > On 04/06/2021 11:11, Laszlo Ersek wrote:
> > > And, to reiterate, just because Confidential Computing is the
> > > new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64,
> > > OvmfPkgX64 do not disappear. Regressing them, or making them
> > > unmaintainable due to skyrocketing complexity, is not acceptable.
> > 
> > Totally agree with this.  Confidential Computing is a very niche
> > use case, and there is no justification for exploding the
> > complexity of the standard OVMF build.
> > 
> > If, several years from now, it ever reaches the point that the
> > majority of real-world workloads are using TDX, then there would be
> > an argument that the complexity cost has to be paid and that the
> > standard OVMF build should include TDX features.  But that's
> > several years away and may never happen.
> 
> Out of interest: does Intel TDX provide any security benefits beyond
> the (much simpler) Intel SGX?

The main benefit is ease of deployment for unmodified applications. 
While you might argue this isn't a "security" benefit, remember that
any security technology that is too complex for most people to deploy
doesn't have much impact, so ease of use is a significant consideration
in security technologies.

> As far as I can tell from the various papers, the fundamental
> difference between TDX and SGX seems to be that TDX deliberately
> increases the attack surface from "just the application code" to
> "entire guest VM, including OS kernel, runtime libraries,
> etc".  Increasing the attack surface while adding complexity is a
> huge cost so I'm assuming that there must be some commensurate
> benefit, but nothing in the documentation I've seen seems to describe
> what this benefit actually is.

The big problems of enclave technology like SGX is rewriting
applications into secure and insecure parts and controlling information
leak across the boundaries of the enclave ... even if you opt to run
the application entirely within the enclave, you still get leaks into
the kernel via syscalls and the machine owner still has a huge amount
of leeway to exfiltrate any secrets in the enclave.

The push towards VM based isolation is because all the handling of the
technology can be done inside an enlightened guest kernel (so any
application will run with no modification) and the guest to host
boundary is a far easier to analyse being a hardware emulation
vmexit/hypercall one rather than the huge and complex syscall
interface.

James




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

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

[Michael Brown]

On 04/06/2021 11:43, Michael Brown wrote:

On 04/06/2021 11:11, Laszlo Ersek wrote:

And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
skyrocketing complexity, is not acceptable.


Totally agree with this.  Confidential Computing is a very niche use 
case, and there is no justification for exploding the complexity of the 
standard OVMF build.


If, several years from now, it ever reaches the point that the majority 
of real-world workloads are using TDX, then there would be an argument 
that the complexity cost has to be paid and that the standard OVMF build 
should include TDX features.  But that's several years away and may 
never happen.


Out of interest: does Intel TDX provide any security benefits beyond the 
(much simpler) Intel SGX?


As far as I can tell from the various papers, the fundamental difference 
between TDX and SGX seems to be that TDX deliberately increases the 
attack surface from "just the application code" to "entire guest VM, 
including OS kernel, runtime libraries, etc".  Increasing the attack 
surface while adding complexity is a huge cost so I'm assuming that 
there must be some commensurate benefit, but nothing in the 
documentation I've seen seems to describe what this benefit actually is.


Thanks,

Michael


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

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

[Michael Brown]

On 04/06/2021 11:11, Laszlo Ersek wrote:

And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
skyrocketing complexity, is not acceptable.


Totally agree with this.  Confidential Computing is a very niche use 
case, and there is no justification for exploding the complexity of the 
standard OVMF build.


If, several years from now, it ever reaches the point that the majority 
of real-world workloads are using TDX, then there would be an argument 
that the complexity cost has to be paid and that the standard OVMF build 
should include TDX features.  But that's several years away and may 
never happen.


Michael


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

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

[Yao, Jiewen]

Intel TDX to exist in a brand new platform, even as
> Stage 1. And, to reiterate, just because Confidential Computing is the
> new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
> do not disappear. Regressing them, or making them unmaintainable due to
> skyrocketing complexity, is not acceptable.
> 
> Thanks
> Laszlo
> 
>> 
>> ===
>> My point is that the "one binary" that the slide deck refers to (i.e.,
>> 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 for
>> 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.
>> =======
>> 
>> Thank you
>> Yao Jiewen
>> 
>>> -Original Message-
>>> From: r...@edk2.groups.io  On Behalf Of Laszlo Ersek
>>> Sent: Friday, June 4, 2021 12:12 AM
>>> To: Yao, Jiewen ; r...@edk2.groups.io;
>>> devel@edk2.groups.io
>>> Cc: j...@linux.ibm.com; Brijesh Singh ; Tom
>>> Lendacky ; erdemak...@google.com;
>>> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
>>> ; Karen Noel ; Paolo Bonzini
>>> ; Nathaniel McCallum ;
>>> Dr. David Alan Gilbert ; Ademar de Souza Reis Jr.
>>> 
>>> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
>>> 
>>>> On 06/03/21 15:51, Yao, Jiewen wrote:
>>>>> 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.
>>> 
>>> Resending my earlier comments in this mailing list thread, with the
>>> feedback inserted at the proper spots that has been given in the
>>> off-list thread since then:
>>> 
>>> 
>>> *** Slides 4, 6, 7: the "one binary requirement".
>>> 
>>> (1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4,
>>> but then the explanation for the requirement, given on slide 7, speaks
>>> about "common attestation interface".
>>> 
>>> I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform
>>> indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP
>>> support. In that sense, adding TDX support to the same platform should
>>> be (hopefully) possible, at the cost of ugly gymnastics in the reset
>>> vector.
>>> 
>>> But "OvmfPkgX64.dsc" is *already* different from the remotely attested
>>> OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc".
>>> 
>>> The latter has some additional modules (secret PEIM and DXE driver), it
>>> has the Grub binary built in, and -- probably most importantly -- it
>>> trusts host-originated information less than "OvmfPkgX64.dsc".
>>> 
>>> For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated
>>> PlatformBootManagerLib instance, one that ignores the non-volatile UEFI
>>> variables Boot and BootOrder, and ignores (thus far) the fw_cfg
>>> originated kernel/initrd/cmdline as well.
>>> 
>>> It remains an "area of research" to see what else should be removed from
>>> the traditional host-guest integration (which integration is usually
>>> desirable for management and convenience), in the remotely-attested boot
>>> scenario. See e.g.
>>> <https://bugzilla.tianocore.org/show_bug.cgi?id=3180>.
>>> 
>>> My point is that the "one binary" that the slide deck refers to (i.e.,
>>> OvmfPkgX64.dsc) might prove OK for utilizing the Intel TDX *technology*
>>> in itself. Simply en

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

[Laszlo Ersek]

 to boot in a TDX domain.
> 
> But "OvmfPkgX64.dsc" is *not* the "one binary" that is suitable for
> 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.
> ===
> 
> Thank you
> Yao Jiewen
> 
>> -Original Message-
>> From: r...@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Friday, June 4, 2021 12:12 AM
>> To: Yao, Jiewen ; r...@edk2.groups.io;
>> devel@edk2.groups.io
>> Cc: j...@linux.ibm.com; Brijesh Singh ; Tom
>> Lendacky ; erdemak...@google.com;
>> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
>> ; Karen Noel ; Paolo Bonzini
>> ; Nathaniel McCallum ;
>> Dr. David Alan Gilbert ; Ademar de Souza Reis Jr.
>> 
>> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
>>
>> On 06/03/21 15:51, Yao, Jiewen wrote:
>>> 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.
>>
>> Resending my earlier comments in this mailing list thread, with the
>> feedback inserted at the proper spots that has been given in the
>> off-list thread since then:
>>
>>
>> *** Slides 4, 6, 7: the "one binary requirement".
>>
>> (1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4,
>> but then the explanation for the requirement, given on slide 7, speaks
>> about "common attestation interface".
>>
>> I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform
>> indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP
>> support. In that sense, adding TDX support to the same platform should
>> be (hopefully) possible, at the cost of ugly gymnastics in the reset
>> vector.
>>
>> But "OvmfPkgX64.dsc" is *already* different from the remotely attested
>> OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc".
>>
>> The latter has some additional modules (secret PEIM and DXE driver), it
>> has the Grub binary built in, and -- probably most importantly -- it
>> trusts host-originated information less than "OvmfPkgX64.dsc".
>>
>> For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated
>> PlatformBootManagerLib instance, one that ignores the non-volatile UEFI
>> variables Boot and BootOrder, and ignores (thus far) the fw_cfg
>> originated kernel/initrd/cmdline as well.
>>
>> It remains an "area of research" to see what else should be removed from
>> the traditional host-guest integration (which integration is usually
>> desirable for management and convenience), in the remotely-attested boot
>> scenario. See e.g.
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=3180>.
>>
>> My point is that the "one binary" that the slide deck refers to (i.e.,
>> 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 for
>> 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.
>>
>>
>> *** Slides 8-9: general boot flow -- TDVF; TDVF Flow
>>
>> I'm likely missing a big bunch of background here, so just a few
>> questions:
>>
>> (2) Not sure what RTMR is, but it's associated with "Enable TrustedBoot"
>> -- so is a virtual TPM a hard requirement?
>>
>> ... Back from slide 10: "TCG measurement and event log framework w/o
>> TPM" -- that's curious.
>>
>> [response from Dave Gilbert:]
>>> My reading of t

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

[Min Xu]

On 06/04/2021 12:12 AM, Laszlo wrote:
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > 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.
> 
> Resending my earlier comments in this mailing list thread, with the feedback
> inserted at the proper spots that has been given in the off-list thread since
> then:
> 
> 
> *** Slides 4, 6, 7: the "one binary requirement".
I would like to hear other reviewers' comments on the "one binary requirement".
> 
> (1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4, but
> then the explanation for the requirement, given on slide 7, speaks about
> "common attestation interface".
> 
> I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform
> indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP
> support. In that sense, adding TDX support to the same platform should be
> (hopefully) possible, at the cost of ugly gymnastics in the reset vector.
> 
> But "OvmfPkgX64.dsc" is *already* different from the remotely attested
> OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc".
> 
> The latter has some additional modules (secret PEIM and DXE driver), it has
> the Grub binary built in, and -- probably most importantly -- it trusts host-
> originated information less than "OvmfPkgX64.dsc".
> 
> For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated
> PlatformBootManagerLib instance, one that ignores the non-volatile UEFI
> variables Boot and BootOrder, and ignores (thus far) the fw_cfg
> originated kernel/initrd/cmdline as well.
> 
> It remains an "area of research" to see what else should be removed from
> the traditional host-guest integration (which integration is usually desirable
> for management and convenience), in the remotely-attested boot scenario.
> See e.g.
> .
> 
> My point is that the "one binary" that the slide deck refers to (i.e.,
> 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 for 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.
> 
> 
> *** Slides 8-9: general boot flow -- TDVF; TDVF Flow
> 
> I'm likely missing a big bunch of background here, so just a few
> questions:
> 
> (2) Not sure what RTMR is, but it's associated with "Enable TrustedBoot"
> -- so is a virtual TPM a hard requirement?
> 
> ... Back from slide 10: "TCG measurement and event log framework w/o
> TPM" -- that's curious.
> 
Comments of Dave & Erdem are pretty good to explain what RTMR is. 
> [response from Dave Gilbert:]
> > My reading of this is that the RTMR (and another set of similar
> > registers) are a TDX thing that is like the PCRs from a TPM but
> > without the rest of the TPM features;  so you can do the one-way
> > measurement into the RTMRs just like you do into a TPM PCR, and the
> > measurements pop out somewhere in the TDX quote.  Just like a TPM you
> > need the event log to make any sense of how the final hashed value
> > supposedly got to where it did.
> 
> [response from Erdem Aktas:]
> > +1 to David on this. TDX provides 2 kinds of measurement registers:
> > MRTDs and RTMRs
> >
> (https://software.intel.com/content/dam/develop/external/us/en/documen
> > ts/tdx-module-1eas-v0.85.039.pdf section 10.1.2) . MRTDs are
> > build-time measurement registers which are updated when TDX is being
> > created. Once TDX is finalized (before the first run), the MRTDs are
> > finalized and cannot be updated anymore. On the other hand, while the
> > TD is running, TD can extend RTMRs through TDCALLs which will provide
> > TPM PCR kind of capabilities.
> 
> ... Back from slide 43: feel free to skip this now; I will comment in more 
> detail
> below.
> 
> (3) Prepare AcpiTable -- OVMF fetches ACPI tables from QEMU; is this a new
> (firmware originated) table that is installed in addition, or does it replace
> QEMU's tables?
> 
> ... Ignore for now, will comment on the MADT stuff later.
> 
> (4) Does DMA management mean a different IOMMU protocol? That is going
> to conflict with the SEV IOMMU protocol. Depexes in OVMF expect one or
> zero IOMMU protocols to be present.
> 
There is only one IOMMU protocol. We will merge TDX features into the current 
SEV IOMMU 

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

[Yao, Jiewen]

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.)

I don't know how "simply" it means. To enable TDX to make it work is not a 
simple work.
Some architecture changes are mandatory, such as reset vector, IO/MMIO access, 
#VE handler, IOMMU based shared memory access, etc. I think AMD SEV already did 
those.

===
My point is that the "one binary" that the slide deck refers to (i.e.,
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 for
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.
===

Thank you
Yao Jiewen

> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Friday, June 4, 2021 12:12 AM
> To: Yao, Jiewen ; r...@edk2.groups.io;
> devel@edk2.groups.io
> Cc: j...@linux.ibm.com; Brijesh Singh ; Tom
> Lendacky ; erdemak...@google.com;
> c...@microsoft.com; bret.barke...@microsoft.com; Jon Lange
> ; Karen Noel ; Paolo Bonzini
> ; Nathaniel McCallum ;
> Dr. David Alan Gilbert ; Ademar de Souza Reis Jr.
> 
> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
> 
> On 06/03/21 15:51, Yao, Jiewen wrote:
> > 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.
> 
> Resending my earlier comments in this mailing list thread, with the
> feedback inserted at the proper spots that has been given in the
> off-list thread since then:
> 
> 
> *** Slides 4, 6, 7: the "one binary requirement".
> 
> (1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4,
> but then the explanation for the requirement, given on slide 7, speaks
> about "common attestation interface".
> 
> I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform
> indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP
> support. In that sense, adding TDX support to the same platform should
> be (hopefully) possible, at the cost of ugly gymnastics in the reset
> vector.
> 
> But "OvmfPkgX64.dsc" is *already* different from the remotely attested
> OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc".
> 
> The latter has some additional modules (secret PEIM and DXE driver), it
> has the Grub binary built in, and -- probably most importantly -- it
> trusts host-originated information less than "OvmfPkgX64.dsc".
> 
> For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated
> PlatformBootManagerLib instance, one that ignores the non-volatile UEFI
> variables Boot and BootOrder, and ignores (thus far) the fw_cfg
> originated kernel/initrd/cmdline as well.
> 
> It remains an "area of research" to see what else should be removed from
> the traditional host-guest integration (which integration is usually
> desirable for management and convenience), in the remotely-attested boot
> scenario. See e.g.
> <https://bugzilla.tianocore.org/show_bug.cgi?id=3180>.
> 
> My point is that the "one binary" that the slide deck refers to (i.e.,
> 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 for
> remote attestation, which has

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

[Laszlo Ersek]

On 06/03/21 15:51, Yao, Jiewen wrote:
> 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.

Resending my earlier comments in this mailing list thread, with the
feedback inserted at the proper spots that has been given in the
off-list thread since then:


*** Slides 4, 6, 7: the "one binary requirement".

(1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4,
but then the explanation for the requirement, given on slide 7, speaks
about "common attestation interface".

I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform
indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP
support. In that sense, adding TDX support to the same platform should
be (hopefully) possible, at the cost of ugly gymnastics in the reset
vector.

But "OvmfPkgX64.dsc" is *already* different from the remotely attested
OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc".

The latter has some additional modules (secret PEIM and DXE driver), it
has the Grub binary built in, and -- probably most importantly -- it
trusts host-originated information less than "OvmfPkgX64.dsc".

For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated
PlatformBootManagerLib instance, one that ignores the non-volatile UEFI
variables Boot and BootOrder, and ignores (thus far) the fw_cfg
originated kernel/initrd/cmdline as well.

It remains an "area of research" to see what else should be removed from
the traditional host-guest integration (which integration is usually
desirable for management and convenience), in the remotely-attested boot
scenario. See e.g.
.

My point is that the "one binary" that the slide deck refers to (i.e.,
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 for
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.


*** Slides 8-9: general boot flow -- TDVF; TDVF Flow

I'm likely missing a big bunch of background here, so just a few
questions:

(2) Not sure what RTMR is, but it's associated with "Enable TrustedBoot"
-- so is a virtual TPM a hard requirement?

... Back from slide 10: "TCG measurement and event log framework w/o
TPM" -- that's curious.

[response from Dave Gilbert:]
> My reading of this is that the RTMR (and another set of similar
> registers) are a TDX thing that is like the PCRs from a TPM but
> without the rest of the TPM features;  so you can do the one-way
> measurement into the RTMRs just like you do into a TPM PCR, and the
> measurements pop out somewhere in the TDX quote.  Just like a TPM you
> need the event log to make any sense of how the final hashed value
> supposedly got to where it did.

[response from Erdem Aktas:]
> +1 to David on this. TDX provides 2 kinds of measurement registers:
> MRTDs and RTMRs
> (https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1eas-v0.85.039.pdf
> section 10.1.2) . MRTDs are build-time measurement registers which are
> updated when TDX is being created. Once TDX is finalized (before the
> first run), the MRTDs are finalized and cannot be updated anymore. On
> the other hand, while the TD is running, TD can extend RTMRs through
> TDCALLs which will provide TPM PCR kind of capabilities.

... Back from slide 43: feel free to skip this now; I will comment in
more detail below.

(3) Prepare AcpiTable -- OVMF fetches ACPI tables from QEMU; is this a
new (firmware originated) table that is installed in addition, or does
it replace QEMU's tables?

... Ignore for now, will comment on the MADT stuff later.

(4) Does DMA management mean a different IOMMU protocol? That is going
to conflict with the SEV IOMMU protocol. Depexes in OVMF expect one or
zero IOMMU protocols to be present.

... Back from slide 40: feel free to skip this now; I'll comment on this
separately, below.

(5) Enumerate VirtIO -- virtio enumeration is PCI based on x86. But I
see no mention of PCI. If you mean VirtioMmioDeviceLib, that's no good,
because it does not support virtio-1.0, only virtio-0.9.5.

... Back from slide 42: I got my answer to this on slide 42, so don't
worry about this point.

(6) The PEI phase is skipped as a whole. I don't see how that can be
reasonably brought together with either