From: Ard Biesheuvel <ardb+git@google.com>
To: stable@vger.kernel.org
Cc: linux-efi@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Borislav Petkov <bp@alien8.de>
Subject: [PATCH stable-v6.1 11/18] x86/efistub: Prefer EFI memory attributes protocol over DXE services
Date: Mon, 4 Mar 2024 12:19:49 +0100 [thread overview]
Message-ID: <20240304111937.2556102-31-ardb+git@google.com> (raw)
In-Reply-To: <20240304111937.2556102-20-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
[ Commit 11078876b7a6a1b7226344fecab968945c806832 upstream ]
Currently, the EFI stub relies on DXE services in some cases to clear
non-execute restrictions from page allocations that need to be
executable. This is dodgy, because DXE services are not specified by
UEFI but by PI, and they are not intended for consumption by OS loaders.
However, no alternative existed at the time.
Now, there is a new UEFI protocol that should be used instead, so if it
exists, prefer it over the DXE services calls.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230807162720.545787-18-ardb@kernel.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
drivers/firmware/efi/libstub/x86-stub.c | 29 ++++++++++++++------
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index adaddd38d97d..01af018b9315 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -26,6 +26,7 @@ const efi_system_table_t *efi_system_table;
const efi_dxe_services_table_t *efi_dxe_table;
u32 image_offset __section(".data");
static efi_loaded_image_t *image = NULL;
+static efi_memory_attribute_protocol_t *memattr;
static efi_status_t
preserve_pci_rom_image(efi_pci_io_protocol_t *pci, struct pci_setup_rom **__rom)
@@ -222,12 +223,18 @@ void efi_adjust_memory_range_protection(unsigned long start,
unsigned long rounded_start, rounded_end;
unsigned long unprotect_start, unprotect_size;
- if (efi_dxe_table == NULL)
- return;
-
rounded_start = rounddown(start, EFI_PAGE_SIZE);
rounded_end = roundup(start + size, EFI_PAGE_SIZE);
+ if (memattr != NULL) {
+ efi_call_proto(memattr, clear_memory_attributes, rounded_start,
+ rounded_end - rounded_start, EFI_MEMORY_XP);
+ return;
+ }
+
+ if (efi_dxe_table == NULL)
+ return;
+
/*
* Don't modify memory region attributes, they are
* already suitable, to lower the possibility to
@@ -758,6 +765,7 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
efi_system_table_t *sys_table_arg,
struct boot_params *boot_params)
{
+ efi_guid_t guid = EFI_MEMORY_ATTRIBUTE_PROTOCOL_GUID;
unsigned long bzimage_addr = (unsigned long)startup_32;
unsigned long buffer_start, buffer_end;
struct setup_header *hdr = &boot_params->hdr;
@@ -769,13 +777,18 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
if (efi_system_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
efi_exit(handle, EFI_INVALID_PARAMETER);
- efi_dxe_table = get_efi_config_table(EFI_DXE_SERVICES_TABLE_GUID);
- if (efi_dxe_table &&
- efi_dxe_table->hdr.signature != EFI_DXE_SERVICES_TABLE_SIGNATURE) {
- efi_warn("Ignoring DXE services table: invalid signature\n");
- efi_dxe_table = NULL;
+ if (IS_ENABLED(CONFIG_EFI_DXE_MEM_ATTRIBUTES)) {
+ efi_dxe_table = get_efi_config_table(EFI_DXE_SERVICES_TABLE_GUID);
+ if (efi_dxe_table &&
+ efi_dxe_table->hdr.signature != EFI_DXE_SERVICES_TABLE_SIGNATURE) {
+ efi_warn("Ignoring DXE services table: invalid signature\n");
+ efi_dxe_table = NULL;
+ }
}
+ /* grab the memory attributes protocol if it exists */
+ efi_bs_call(locate_protocol, &guid, NULL, (void **)&memattr);
+
status = efi_setup_5level_paging();
if (status != EFI_SUCCESS) {
efi_err("efi_setup_5level_paging() failed!\n");
--
2.44.0.278.ge034bb2e1d-goog
next prev parent reply other threads:[~2024-03-04 11:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 11:19 [PATCH stable-v6.1 00/18] efistub/x86 changes for secure boot Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 01/18] arm64: efi: Limit allocations to 48-bit addressable physical region Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 02/18] efi: efivars: prevent double registration Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 03/18] x86/efistub: Simplify and clean up handover entry code Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 04/18] x86/decompressor: Avoid magic offsets for EFI handover entrypoint Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 05/18] x86/efistub: Clear BSS in EFI handover protocol entrypoint Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 06/18] x86/decompressor: Move global symbol references to C code Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 07/18] efi/libstub: Add memory attribute protocol definitions Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 08/18] efi/libstub: Add limit argument to efi_random_alloc() Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 09/18] x86/efistub: Perform 4/5 level paging switch from the stub Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 10/18] x86/decompressor: Factor out kernel decompression and relocation Ard Biesheuvel
2024-03-04 11:19 ` Ard Biesheuvel [this message]
2024-03-04 11:19 ` [PATCH stable-v6.1 12/18] x86/efistub: Perform SNP feature test while running in the firmware Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 13/18] x86/efistub: Avoid legacy decompressor when doing EFI boot Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 14/18] efi/x86: Avoid physical KASLR on older Dell systems Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 15/18] x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 16/18] x86/boot: Rename conflicting 'boot_params' pointer to 'boot_params_ptr' Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 17/18] x86/boot: efistub: Assign global boot_params variable Ard Biesheuvel
2024-03-04 11:19 ` [PATCH stable-v6.1 18/18] efi/x86: Fix the missing KASLR_FLAG bit in boot_params->hdr.loadflags Ard Biesheuvel
2024-03-04 11:42 ` [PATCH stable-v6.1 00/18] efistub/x86 changes for secure boot Greg KH
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=20240304111937.2556102-31-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=linux-efi@vger.kernel.org \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox