All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: <linux-kernel@vger.kernel.org>, <x86@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Michael Roth <michael.roth@amd.com>,
	Joerg Roedel <jroedel@suse.de>,
	Dionna Glaze <dionnaglaze@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	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>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: [RESEND PATCH v8 6/6] x86/efi: Safely enable unaccepted memory in UEFI
Date: Fri, 19 May 2023 11:30:13 -0500	[thread overview]
Message-ID: <430269747cb961c7e70288b5808925f4fa4c544d.1684513813.git.thomas.lendacky@amd.com> (raw)
In-Reply-To: <cover.1684513813.git.thomas.lendacky@amd.com>

From: Dionna Glaze <dionnaglaze@google.com>

The UEFI v2.9 specification includes a new memory type to be used in
environments where the OS must accept memory that is provided from its
host. Before the introduction of this memory type, all memory was
accepted eagerly in the firmware. In order for the firmware to safely
stop accepting memory on the OS's behalf, the OS must affirmatively
indicate support to the firmware. This is only a problem for AMD
SEV-SNP, since Linux has had support for it since 5.19. The other
technology that can make use of unaccepted memory, Intel TDX, does not
yet have Linux support, so it can strictly require unaccepted memory
support as a dependency of CONFIG_TDX and not require communication with
the firmware.

Enabling unaccepted memory requires calling a 0-argument enablement
protocol before ExitBootServices. This call is only made if the kernel
is compiled with UNACCEPTED_MEMORY=y

This protocol will be removed after the end of life of the first LTS
that includes it, in order to give firmware implementations an
expiration date for it. When the protocol is removed, firmware will
strictly infer that a SEV-SNP VM is running an OS that supports the
unaccepted memory type. At the earliest convenience, when unaccepted
memory support is added to Linux, SEV-SNP may take strict dependence in
it. After the firmware removes support for the protocol, this patch
should be reverted.

  [tl: address some checkscript warnings]

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: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 drivers/firmware/efi/libstub/x86-stub.c | 36 +++++++++++++++++++++++++
 include/linux/efi.h                     |  3 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 8d17cee8b98e..e2193dbe1f66 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -26,6 +26,17 @@ const efi_dxe_services_table_t *efi_dxe_table;
 u32 image_offset __section(".data");
 static efi_loaded_image_t *image = NULL;
 
+typedef union sev_memory_acceptance_protocol sev_memory_acceptance_protocol_t;
+union sev_memory_acceptance_protocol {
+	struct {
+		efi_status_t (__efiapi * allow_unaccepted_memory)(
+			sev_memory_acceptance_protocol_t *);
+	};
+	struct {
+		u32 allow_unaccepted_memory;
+	} mixed_mode;
+};
+
 static efi_status_t
 preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
 {
@@ -310,6 +321,29 @@ setup_memory_protection(unsigned long image_base, unsigned long image_size)
 #endif
 }
 
+static void setup_unaccepted_memory(void)
+{
+	efi_guid_t mem_acceptance_proto = OVMF_SEV_MEMORY_ACCEPTANCE_PROTOCOL_GUID;
+	sev_memory_acceptance_protocol_t *proto;
+	efi_status_t status;
+
+	if (!IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+		return;
+
+	/*
+	 * Enable unaccepted memory before calling exit boot services in order
+	 * for the UEFI to not accept all memory on EBS.
+	 */
+	status = efi_bs_call(locate_protocol, &mem_acceptance_proto, NULL,
+			     (void **)&proto);
+	if (status != EFI_SUCCESS)
+		return;
+
+	status = efi_call_proto(proto, allow_unaccepted_memory);
+	if (status != EFI_SUCCESS)
+		efi_err("Memory acceptance protocol failed\n");
+}
+
 static const efi_char16_t apple[] = L"Apple";
 
 static void setup_quirks(struct boot_params *boot_params,
@@ -908,6 +942,8 @@ asmlinkage unsigned long efi_main(efi_handle_t handle,
 
 	setup_quirks(boot_params, bzimage_addr, buffer_end - buffer_start);
 
+	setup_unaccepted_memory();
+
 	status = exit_boot(boot_params, handle);
 	if (status != EFI_SUCCESS) {
 		efi_err("exit_boot() failed!\n");
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 9864f9c00da2..8c5abcf70a05 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -437,6 +437,9 @@ void efi_native_runtime_setup(void);
 #define DELLEMC_EFI_RCI2_TABLE_GUID		EFI_GUID(0x2d9f28a2, 0xa886, 0x456a,  0x97, 0xa8, 0xf1, 0x1e, 0xf2, 0x4f, 0xf4, 0x55)
 #define AMD_SEV_MEM_ENCRYPT_GUID		EFI_GUID(0x0cf29b71, 0x9e51, 0x433a,  0xa3, 0xb7, 0x81, 0xf3, 0xab, 0x16, 0xb8, 0x75)
 
+/* OVMF protocol GUIDs */
+#define OVMF_SEV_MEMORY_ACCEPTANCE_PROTOCOL_GUID	EFI_GUID(0xc5a010fe, 0x38a7, 0x4531,  0x8a, 0x4a, 0x05, 0x00, 0xd2, 0xfd, 0x16, 0x49)
+
 typedef struct {
 	efi_guid_t guid;
 	u64 table;
-- 
2.40.0


      parent reply	other threads:[~2023-05-19 16:32 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 23:14 [PATCHv12 0/9] mm, x86/cc, efi: Implement support for unaccepted memory Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 1/9] mm: Add " Kirill A. Shutemov
2023-05-31 15:51   ` Borislav Petkov
2023-05-31 16:27     ` Kirill A. Shutemov
2023-05-31 17:50       ` Borislav Petkov
2023-05-31 18:10         ` [PATCHv12.1 " Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 2/9] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 3/9] efi/libstub: Implement support for unaccepted memory Kirill A. Shutemov
2023-05-19 15:12   ` Tom Lendacky
2023-05-18 23:14 ` [PATCHv12 4/9] x86/boot/compressed: Handle " Kirill A. Shutemov
2023-05-19 10:16   ` Kirill A. Shutemov
2023-05-22 11:01     ` Kirill A. Shutemov
2023-05-22 11:08       ` Ard Biesheuvel
2023-05-18 23:14 ` [PATCHv12 5/9] efi: Add unaccepted memory support Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 6/9] efi/unaccepted: Avoid load_unaligned_zeropad() stepping into unaccepted memory Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 7/9] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 8/9] x86/tdx: Refactor try_accept_one() Kirill A. Shutemov
2023-05-18 23:14 ` [PATCHv12 9/9] x86/tdx: Add unaccepted memory support Kirill A. Shutemov
2023-05-31  0:58   ` Isaku Yamahata
2023-05-31 12:25     ` Kirill A. Shutemov
2023-05-19 16:24 ` [PATCH 1/6] x86/sev: Fix calculation of end address based on number of pages Tom Lendacky
2023-05-19 16:31   ` Tom Lendacky
2023-05-19 16:24 ` [PATCH 2/6] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2023-05-19 16:24 ` [PATCH 3/6] x86/sev: Allow for use of the early boot GHCB for PSC requests Tom Lendacky
2023-05-19 16:24 ` [PATCH 4/6] x86/sev: Use large PSC requests if applicable Tom Lendacky
2023-05-19 16:24 ` [PATCH 5/6] x86/sev: Add SNP-specific unaccepted memory support Tom Lendacky
2023-05-19 16:24 ` [PATCH 6/6] x86/efi: Safely enable unaccepted memory in UEFI Tom Lendacky
2023-05-19 16:30 ` [RESEND PATCH v8 0/6] Provide SEV-SNP support for unaccepted memory Tom Lendacky
2023-05-19 16:30   ` [RESEND PATCH v8 1/6] x86/sev: Fix calculation of end address based on number of pages Tom Lendacky
2023-05-19 16:30   ` [RESEND PATCH v8 2/6] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2023-05-19 16:30   ` [RESEND PATCH v8 3/6] x86/sev: Allow for use of the early boot GHCB for PSC requests Tom Lendacky
2023-05-19 16:30   ` [RESEND PATCH v8 4/6] x86/sev: Use large PSC requests if applicable Tom Lendacky
2023-06-06 10:46     ` Borislav Petkov
2023-05-19 16:30   ` [RESEND PATCH v8 5/6] x86/sev: Add SNP-specific unaccepted memory support Tom Lendacky
2023-05-19 16:30   ` Tom Lendacky [this message]

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-all 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=430269747cb961c7e70288b5808925f4fa4c544d.1684513813.git.thomas.lendacky@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=erdemaktas@google.com \
    --cc=hpa@zytor.com \
    --cc=jejb@linux.ibm.com \
    --cc=jiewen.yao@intel.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=min.m.xu@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.