| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk>
Date: Fri, 25 Sep 2015 23:02:18 +0100
From: Matt Fleming <matt@...eblueprint.co.uk>
To: Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Cc: Matt Fleming <matt.fleming@...el.com>,
linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
"Lee, Chun-Yi" <jlee@...e.com>, Borislav Petkov <bp@...e.de>,
Leif Lindholm <leif.lindholm@...aro.org>,
Peter Jones <pjones@...hat.com>,
James Bottomley <JBottomley@...n.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Dave Young <dyoung@...hat.com>, <stable@...r.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime
From: Matt Fleming <matt.fleming@...el.com>
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
signals that the firmware PE/COFF loader supports splitting code and
data sections of PE/COFF images into separate EFI memory map entries.
This allows the kernel to map those regions with strict memory
protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is that
the regions need to be mapped with the same offsets relative to each
other as observed in the EFI memory map. If this is not done crashes
like this may occur,
[ 0.006391] BUG: unable to handle kernel paging request at fffffffefe6086dd
[ 0.006923] IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
[ 0.007000] Call Trace:
[ 0.007000] [<ffffffff8104c90e>] efi_call+0x7e/0x100
[ 0.007000] [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
[ 0.007000] [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
[ 0.007000] [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
[ 0.007000] [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
[ 0.007000] [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
[ 0.007000] [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
Here 0xfffffffefe6086dd refers to an address the firmware expects to
be mapped but which the OS never claimed was mapped. The issue is that
included in these regions are relative addresses to other regions
which were emitted by the firmware toolchain before the "splitting" of
sections occurred at runtime.
Needless to say, we don't satisfy this unwritten requirement on x86_64
and instead map the EFI memory map entries in reverse order. The above
crash is almost certainly triggerable with any kernel newer than v3.13
because that's when we rewrote the EFI runtime region mapping code, in
commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For
kernel versions before v3.13 things may work by pure luck depending on
the fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order, where
entry N has a higher virtual address than entry N+1, map them in the
same order as they appear in the EFI memory map to preserve this
relative offset between regions.
This patch has been kept as small as possible with the intention that
it should be applied aggressively to stable and distribution kernels.
It is very much a bugfix rather than support for a new feature, since
when EFI_PROPERTIES_TABLE is enabled we must map things as outlined
above to even boot - we have no way of asking the firmware not to
split the code/data regions.
In fact, this patch doesn't even make use of the more strict memory
protections available in UEFI v2.5. That will come later.
Reported-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: "Lee, Chun-Yi" <jlee@...e.com>
Cc: Borislav Petkov <bp@...e.de>
Cc: Leif Lindholm <leif.lindholm@...aro.org>
Cc: Peter Jones <pjones@...hat.com>
Cc: James Bottomley <JBottomley@...n.com>
Cc: Matthew Garrett <mjg59@...f.ucam.org>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Dave Young <dyoung@...hat.com>
Cc: <stable@...r.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@...el.com>
---
arch/x86/platform/efi/efi.c | 67 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1db84c0758b7..6a28ded74211 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -705,6 +705,70 @@ out:
}
/*
+ * Iterate the EFI memory map in reverse order because the regions
+ * will be mapped top-down. The end result is the same as if we had
+ * mapped things forward, but doesn't require us to change the
+ * existing implementation of efi_map_region().
+ */
+static inline void *efi_map_next_entry_reverse(void *entry)
+{
+ /* Initial call */
+ if (!entry)
+ return memmap.map_end - memmap.desc_size;
+
+ entry -= memmap.desc_size;
+ if (entry < memmap.map)
+ return NULL;
+
+ return entry;
+}
+
+/*
+ * efi_map_next_entry - Return the next EFI memory map descriptor
+ * @entry: Previous EFI memory map descriptor
+ *
+ * This is a helper function to iterate over the EFI memory map, which
+ * we do in different orders depending on the current configuration.
+ *
+ * To begin traversing the memory map @entry must be %NULL.
+ *
+ * Returns %NULL when we reach the end of the memory map.
+ */
+static void *efi_map_next_entry(void *entry)
+{
+ if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
+ /*
+ * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
+ * config table feature requires us to map all entries
+ * in the same order as they appear in the EFI memory
+ * map. That is to say, entry N must have a lower
+ * virtual address than entry N+1. This is because the
+ * firmware toolchain leaves relative references in
+ * the code/data sections, which are split and become
+ * separate EFI memory regions. Mapping things
+ * out-of-order leads to the firmware accessing
+ * unmapped addresses.
+ *
+ * Since we need to map things this way whether or not
+ * the kernel actually makes use of
+ * EFI_PROPERTIES_TABLE, let's just switch to this
+ * scheme by default for 64-bit.
+ */
+ return efi_map_next_entry_reverse(entry);
+ }
+
+ /* Initial call */
+ if (!entry)
+ return memmap.map;
+
+ entry += memmap.desc_size;
+ if (entry >= memmap.map_end)
+ return NULL;
+
+ return entry;
+}
+
+/*
* Map the efi memory ranges of the runtime services and update new_mmap with
* virtual addresses.
*/
@@ -714,7 +778,8 @@ static void * __init efi_map_regions(int *count, int *pg_shift)
unsigned long left = 0;
efi_memory_desc_t *md;
- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ p = NULL;
+ while ((p = efi_map_next_entry(p))) {
md = p;
if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
#ifdef CONFIG_X86_64
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists