public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Dionna Glaze" <dionnaglaze@google.com>
To: devel@edk2.groups.io
Cc: Dionna Glaze <dionnaglaze@google.com>,
	Ard Biescheuvel <ardb@kernel.org>,
	 "Min M. Xu" <min.m.xu@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	 James Bottomley <jejb@linux.ibm.com>,
	Tom Lendacky <Thomas.Lendacky@amd.com>,
	 Jiewen Yao <jiewen.yao@intel.com>,
	Erdem Aktas <erdemaktas@google.com>,
	 Andrew Fish <afish@apple.com>,
	"Michael D. Kinney" <michael.d.kinney@intel.com>
Subject: [PATCH v6 0/7] Add safe unaccepted memory behavior
Date: Mon,  3 Oct 2022 18:53:45 +0000	[thread overview]
Message-ID: <20221003185352.3969999-1-dionnaglaze@google.com> (raw)

These seven patches build on the lazy-accept patch series

"Introduce Lazy-accept for Tdx guest"

by adding SEV-SNP support for the MemoryAccept protocol, and
importantly making eager memory acceptance the default behavior.

We add a new protocol, ExitBootServicesCallbackProtocol, with a single
interface: TerminateMemoryMapPrehook(). We invoke all prehooks in
CoreExitBootServices after disabling the timer and before
TerminateMemoryMap. This gives hooks the chance to change the memory
map and cause ExitBootServices to fail with EFI_INVALID_PARAMETER.
The failure is specified to require the caller to update their view
of the MemoryMap and call ExitBootServices again.

To make use of this new protocol, we add a new driver that is meant to
carry behavior that is needed for all confidential compute technologies,
not just specific platforms, CocoDxe. In CocoDxe we implement the
default safe behavior to accept all unaccepted memory and invalidate
the MemoryMap on ExitBootServices.

To allow the OS loader to prevent the eager acceptance, add another
protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol.
This protocol has one interface, Disable(). The OS loader can inform the
UEFI that it supports the unaccepted memory type and accepts the
responsibility to accept it.

All images that support unaccepted memory must now locate and call this
new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable
function.

Changes since v5:
 - Generic callback protocol moved to MdeModulePkg
 - Removed use of EFI_WARN_STALE_DATA and added comment that the callback
   should only return EFI_SUCCESS or EFI_INVALID_PARAMETER.
 - Removed errant log statement and fixed formatting.

Changes since v4:
 - Commit message wording
 - Replaced direct change to DxeMain with a more generic callback
   protocol.
 - Implemented the direct change as an instance of the callback protocol
   from a new CocoDxe driver.
 - Replaced "enable" protocol with a "disable" protocol, since the name
   was confusing. The AcceptAllUnacceptedMemory protocol directly names
   the behavior that is disabling.

Changes since v3:
 - "DxeMain accepts all memory" patch split into 3 to make each patch
   affect only one package at a time.

Changes since v2:
 - Removed the redundant memory accept interface and added the accept
   behavior to the DXE implementation of
   MemEncryptSevSnpPreValidateSystemRam.
 - Fixed missing #include in >=4GB patch.

Changes since v1:
 - Added a patch to classify SEV-SNP memory above 4GB unaccepted.
 - Fixed style problems in EfiMemoryAcceptProtocol implementation.

Cc: Ard Biescheuvel <ardb@kernel.org>
Cc: "Min M. Xu" <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Andrew Fish <afish@apple.com>
Cc: "Michael D. Kinney" <michael.d.kinney@intel.com>

Dionna Glaze (7):
  OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
  MdeModulePkg: Introduce ExitBootServicesCallbackProtocol
  MdeModulePkg: Invoke all ExitBootServicesCallback instances at
    ExitBootServices
  OvmfPkg: Introduce CocoDxe driver
  MdePkg: Introduce the AcceptAllUnacceptedMemory protocol
  OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe
  OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted

 MdeModulePkg/Core/Dxe/DxeMain.h                                    |   1 +
 MdeModulePkg/Core/Dxe/DxeMain.inf                                  |   1 +
 MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c                            |  41 +++++
 MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h           |  40 +++++
 MdeModulePkg/MdeModulePkg.dec                                      |   3 +
 MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h          |  40 +++++
 MdePkg/MdePkg.dec                                                  |   3 +
 OvmfPkg/AmdSev/AmdSevX64.dsc                                       |   1 +
 OvmfPkg/AmdSev/AmdSevX64.fdf                                       |   1 +
 OvmfPkg/AmdSevDxe/AmdSevDxe.c                                      |  55 ++++++-
 OvmfPkg/AmdSevDxe/AmdSevDxe.inf                                    |   3 +
 OvmfPkg/CocoDxe/CocoDxe.c                                          | 169 ++++++++++++++++++++
 OvmfPkg/CocoDxe/CocoDxe.inf                                        |  44 +++++
 OvmfPkg/IntelTdx/IntelTdxX64.dsc                                   |   1 +
 OvmfPkg/IntelTdx/IntelTdxX64.fdf                                   |   1 +
 OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c |  24 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc                                         |   1 +
 OvmfPkg/OvmfPkgIa32X64.fdf                                         |   1 +
 OvmfPkg/OvmfPkgX64.dsc                                             |   1 +
 OvmfPkg/OvmfPkgX64.fdf                                             |   1 +
 OvmfPkg/PlatformPei/AmdSev.c                                       |   5 +
 21 files changed, 429 insertions(+), 8 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/ExitBootServicesCallback.h
 create mode 100644 MdePkg/Include/Protocol/Bz3987AcceptAllUnacceptedMemory.h
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c
 create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf

-- 
2.38.0.rc1.362.ged0d419d3c-goog


             reply	other threads:[~2022-10-03 18:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 18:53 Dionna Glaze [this message]
2022-10-03 18:53 ` [PATCH v6 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 2/7] MdeModulePkg: Introduce ExitBootServicesCallbackProtocol Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 4/7] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2022-10-03 18:53 ` [PATCH v6 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze

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=20221003185352.3969999-1-dionnaglaze@google.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