public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "James Bottomley" <jejb@linux.ibm.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Cc: "Xu, Min M" <min.m.xu@intel.com>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nathaniel McCallum <npmccallum@redhat.com>
Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest]
Date: Mon, 12 Apr 2021 07:33:52 -0700	[thread overview]
Message-ID: <e5a819b922730889c7faec08ceece65de7668b6d.camel@linux.ibm.com> (raw)
In-Reply-To: <BY5PR11MB4166FCB474FF5F87D9BE4C768C709@BY5PR11MB4166.namprd11.prod.outlook.com>

On Mon, 2021-04-12 at 11:54 +0000, Yao, Jiewen wrote:
> I totally agree with you that from security perspective, the best
> idea to isolate AMD SEV/Intel TDX from standard OVMF.

There's a big difference between building tuned binaries and separating
the subsystems entirely.  Ideally we don't want customers running
images to have to build them differently for Intel or AMD (a bit like
how QEMU/KVM hide the VM differences from users), and Confidential
Computing shares a huge amount of interface similarity, so we wouldn't
want that separated.  I think the rule should be that if both Intel and
AMD expose a feature in different ways, OVMF tries to expose a uniform
API for that feature over two differing implementations.

> Do you want to propose move AMD SEV support to another SEC?

You mean have an entirely separate SEC for AMD, OVMF and Intel?  I
really wouldn't do that: much that's in the SEC: page table setup,
memory mapping and decompression is common to all of them.  This all
follows for a lot of the components.

To build separate binaries, we just need separate dsc and fdf files. 
Then I think the goal would be to share as much as possible to avoid
duplicating the maintenance and possibly diverging the user API.

James



  reply	other threads:[~2021-04-12 14:34 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 15:31 [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support brijesh.singh
2021-03-24 15:31 ` [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest Brijesh Singh
2021-04-06  8:11   ` Min Xu
2021-04-06 12:16     ` Laszlo Ersek
2021-04-07  0:21       ` Min Xu
2021-04-07  0:44         ` James Bottomley
2021-04-07 15:02           ` Laszlo Ersek
2021-04-07 15:12             ` James Bottomley
2021-04-08  6:24             ` [edk2-devel] " Min Xu
2021-04-08 13:31               ` Lendacky, Thomas
2021-04-09 12:29                 ` Laszlo Ersek
2021-04-09 13:32                 ` Laszlo Ersek
2021-04-09 13:44                   ` Yao, Jiewen
2021-04-09 14:11                     ` separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest] Laszlo Ersek
2021-04-12  8:35                       ` Dr. David Alan Gilbert
2021-04-12 11:54                         ` [edk2-devel] " Yao, Jiewen
2021-04-12 14:33                           ` James Bottomley [this message]
2021-04-14 23:34                             ` erdemaktas
2021-04-15  7:59                               ` Paolo Bonzini
2021-04-15 19:42                                 ` Erdem Aktas
2021-04-21  0:38                                   ` Yao, Jiewen
2021-04-21 10:44                                     ` Laszlo Ersek
2021-04-21 17:07                                       ` Erdem Aktas
2021-04-22 14:20                                         ` Laszlo Ersek
2021-04-07 13:22         ` [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest Laszlo Ersek
2021-04-07 13:24           ` Laszlo Ersek
2021-04-08  0:45           ` Min Xu
2021-04-07  0:31       ` James Bottomley
2021-04-12 14:52   ` Brijesh Singh
2021-04-13  9:49     ` Laszlo Ersek
2021-04-13 11:29       ` Brijesh Singh
2021-04-13 13:13         ` Laszlo Ersek
2021-04-19 21:42       ` Brijesh Singh
2021-04-20  8:14         ` Laszlo Ersek
2021-03-24 15:31 ` [RFC PATCH 02/19] OvmfPkg: validate the data pages used in the SEC phase Brijesh Singh
2021-03-24 15:31 ` [RFC PATCH 03/19] MdePkg: Expand the SEV MSR to include the SNP definition Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 04/19] OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled() Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 05/19] MdePkg: Define the GHCB GPA structure Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 06/19] UefiCpuPkg/MpLib: add support to register GHCB GPA when SEV-SNP is enabled Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 07/19] OvmfPkg: Add a library to support registering GHCB GPA Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 08/19] OvmfPkg: register GHCB gpa for the SEV-SNP guest Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 09/19] MdePkg: Add AsmPvalidate() support Brijesh Singh
2021-03-25  2:49   ` 回复: [edk2-devel] " gaoliming
2021-03-25 10:54     ` Brijesh Singh
2021-03-26 20:02       ` Andrew Fish
2021-03-24 15:32 ` [RFC PATCH 10/19] OvmfPkg: Define the Page State Change VMGEXIT structures Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 11/19] OvmfPkg/ResetVector: Invalidate the GHCB page Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 12/19] OvmfPkg/MemEncryptSevLib: Add support to validate system RAM Brijesh Singh
2021-04-01  6:37   ` Yao, Jiewen
2021-04-01 13:07     ` Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 13/19] OvmfPkg/SecMain: Validate the data/code pages used for the PEI phase Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 14/19] OvmfPkg/MemEncryptSevLib: Add support to validate RAM in " Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 15/19] OvmfPkg/PlatformPei: Validate the system RAM when SNP is active Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 16/19] OvmfPkg/MemEncryptSevLib: Add support to validate > 4GB memory in PEI phase Brijesh Singh
2021-04-01  6:43   ` Yao, Jiewen
2021-03-24 15:32 ` [RFC PATCH 17/19] OvmfPkg/VmgExitLib: Allow PMBASE register access in Dxe phase Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 18/19] OvmfPkg/MemEncryptSevLib: Validate the memory during set or clear enc attribute Brijesh Singh
2021-03-24 20:07   ` Brijesh Singh
2021-03-24 15:32 ` [RFC PATCH 19/19] OvmfPkg/MemEncryptSevLib: Skip page state change for non RAM region Brijesh Singh
2021-03-24 19:14 ` [edk2-devel] [RFC PATCH 00/19] Add AMD Secure Nested Paging (SEV-SNP) support Laszlo Ersek
2021-04-08  9:58 ` Laszlo Ersek
2021-04-08 11:59   ` Brijesh Singh
2021-04-09 12:24     ` Laszlo Ersek
2021-04-09 22:43       ` Brijesh Singh
2021-04-12 16:23         ` Laszlo Ersek
2021-04-12 20:14           ` Brijesh Singh
2021-04-13 13:00             ` Laszlo Ersek
2021-04-14 11:18               ` Brijesh Singh

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=e5a819b922730889c7faec08ceece65de7668b6d.camel@linux.ibm.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