public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"erdemaktas@google.com" <erdemaktas@google.com>,
	"cho@microsoft.com" <cho@microsoft.com>,
	"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
	Jon Lange <jlange@microsoft.com>, Karen Noel <knoel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nathaniel McCallum <npmccallum@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Ademar de Souza Reis Jr." <areis@redhat.com>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
Date: Tue, 22 Jun 2021 15:34:35 +0200	[thread overview]
Message-ID: <4d0fc023-6520-43f6-0b0e-9db7bf15a85c@redhat.com> (raw)
In-Reply-To: <PH0PR11MB506473EFD3D5FF95ADD6CC1CC5349@PH0PR11MB5064.namprd11.prod.outlook.com>

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 <devel@edk2.groups.io> On Behalf Of Min Xu
> Sent: Friday, June 11, 2021 6:30 AM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; rfc@edk2.groups.io
> Cc: jejb@linux.ibm.com; Laszlo Ersek <lersek@redhat.com>; Brijesh Singh <brijesh.singh@amd.com>; Tom Lendacky <thomas.lendacky@amd.com>; erdemaktas@google.com; cho@microsoft.com; bret.barkelew@microsoft.com; Jon Lange <jlange@microsoft.com>; Karen Noel <knoel@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Nathaniel McCallum <npmccallum@redhat.com>; Dr. David Alan Gilbert <dgilbert@redhat.com>; Ademar de Souza Reis Jr. <areis@redhat.com>
> Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
> 
> Hi, All
> Thanks much for the valuable comments and discussion about the design.
> We have updated the slides (v0.9) in below link. If some comments or concerns are not answered/addressed in the new slides, please don't hesitate to tell us. We do want to answer/address all the comments/concerns. But to be honest it is a rather complicated one and we appreciate your feedbacks.
> https://edk2.groups.io/g/devel/files/Designs/2021/0611/TDVF_Design_Review%28v0.9%29.pptx
> 
> Thanks much!
> 
> Xu Min
> 
> 
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Yao, Jiewen
> Sent: Thursday, June 3, 2021 9:51 PM
> To: rfc@edk2.groups.io<mailto:rfc@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> Cc: jejb@linux.ibm.com<mailto:jejb@linux.ibm.com>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Brijesh Singh <brijesh.singh@amd.com<mailto:brijesh.singh@amd.com>>; Tom Lendacky <thomas.lendacky@amd.com<mailto:thomas.lendacky@amd.com>>; erdemaktas@google.com<mailto:erdemaktas@google.com>; cho@microsoft.com<mailto:cho@microsoft.com>; bret.barkelew@microsoft.com<mailto:bret.barkelew@microsoft.com>; Jon Lange <jlange@microsoft.com<mailto:jlange@microsoft.com>>; Karen Noel <knoel@redhat.com<mailto:knoel@redhat.com>>; Paolo Bonzini <pbonzini@redhat.com<mailto:pbonzini@redhat.com>>; Nathaniel McCallum <npmccallum@redhat.com<mailto:npmccallum@redhat.com>>; Dr. David Alan Gilbert <dgilbert@redhat.com<mailto:dgilbert@redhat.com>>; Ademar de Souza Reis Jr. <areis@redhat.com<mailto:areis@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
> 
> 
> 
> 
> 
> 
> 


  reply	other threads:[~2021-06-22 13:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 13:51 [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Yao, Jiewen
2021-06-03 16:11 ` Laszlo Ersek
2021-06-03 23:19   ` Yao, Jiewen
2021-06-04 10:11     ` Laszlo Ersek
2021-06-04 10:24       ` Yao, Jiewen
2021-06-04 10:43       ` Michael Brown
2021-06-04 14:52         ` Michael Brown
2021-06-04 15:04           ` James Bottomley
2021-06-04  7:33   ` Min Xu
2021-06-06  2:03   ` Min Xu
2021-06-06 11:29     ` Michael Brown
2021-06-06 12:49       ` Min Xu
2021-06-07 13:52         ` Laszlo Ersek
2021-06-06  8:52   ` Min Xu
2021-06-06 11:39     ` Michael Brown
2021-06-08 12:27   ` Min Xu
2021-06-08 15:36     ` Laszlo Ersek
2021-06-08 16:01 ` James Bottomley
2021-06-08 19:33   ` Laszlo Ersek
2021-06-09  0:58     ` Min Xu
2021-06-09 11:00       ` Laszlo Ersek
2021-06-09 14:36         ` James Bottomley
2021-06-09  2:01   ` Min Xu
2021-06-09 14:28     ` James Bottomley
2021-06-09 15:47       ` Paolo Bonzini
2021-06-09 15:59         ` James Bottomley
2021-06-10 21:01           ` Erdem Aktas
2021-06-10 22:30 ` Min Xu
2021-06-11  1:33   ` James Bottomley
2021-06-11  1:36     ` Yao, Jiewen
2021-06-11  1:38       ` James Bottomley
2021-06-11  1:55         ` James Bottomley
     [not found] ` <168759329436FBCF.5845@groups.io>
2021-06-11  6:37   ` Min Xu
2021-06-22 13:34     ` Laszlo Ersek [this message]
2021-06-22 13:38       ` Laszlo Ersek
2021-06-24  0:24         ` Min Xu
2021-06-24  0:35           ` James Bottomley
2021-06-24  0:55             ` Min Xu
     [not found]             ` <168B5EA81BA66FAC.7570@groups.io>
2021-07-01  5:00               ` Min Xu
2021-06-23  2:44       ` Min Xu
2021-06-23 17:47         ` Laszlo Ersek
2021-06-23 11:56       ` Min Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d0fc023-6520-43f6-0b0e-9db7bf15a85c@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox