Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1616170 > unrolled thread

[PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region

Started byArd Biesheuvel <ard.biesheuvel@linaro.org>
First post2017-04-04 18:10 +0200
Last post2017-04-07 18:10 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-04-04 18:10 +0200
    [tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI  rt services region tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-04-05 11:10 +0200
    [tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI  rt services region tip-bot for Ard Biesheuvel <tipbot@zytor.com> - 2017-04-05 12:50 +0200
    Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the  UEFI rt services region Catalin Marinas <catalin.marinas@arm.com> - 2017-04-07 18:00 +0200
      Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the  UEFI rt services region Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-04-07 18:10 +0200

#1616170 — [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-04-04 18:10 +0200
Subject[PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region
Message-ID<tszbR-78Z-41@gated-at.bofh.it>
Update the allocation logic for the virtual mapping of the UEFI runtime
services to start from a randomized base address if KASLR is in effect,
and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.

This makes it more difficult to predict the location of exploitable
data structures in the runtime UEFI firmware, which increases robustness
against attacks. Note that these regions are only mapped during the
time a runtime service call is in progress, and only on a single CPU
at a time, bit give the lack of a downside, let's enable it nonetheless.

Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 657bb72c9e0b..1e45ec51b094 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,6 +18,22 @@
 
 #include "efistub.h"
 
+/*
+ * This is the base address at which to start allocating virtual memory ranges
+ * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
+ * any allocation we choose, and eliminate the risk of a conflict after kexec.
+ * The value chosen is the largest non-zero power of 2 suitable for this purpose
+ * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
+ * be mapped efficiently.
+ * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
+ * map everything below 1 GB. (512 MB is a reasonable upper bound for the
+ * entire footprint of the UEFI runtime services memory regions)
+ */
+#define EFI_RT_VIRTUAL_BASE	SZ_512M
+#define EFI_RT_VIRTUAL_SIZE	SZ_512M
+
+static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
+
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 			     void *__image, void **__fh)
 {
@@ -213,6 +229,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	efi_random_get_seed(sys_table);
 
+	if (!nokaslr()) {
+		/*
+		 * Randomize the base of the UEFI runtime services region.
+		 * Preserve the 2 MB alignment of the region by taking a
+		 * shift of 21 bit positions into account when scaling
+		 * the headroom value using a 32-bit random value.
+		 */
+		u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
+			       EFI_RT_VIRTUAL_SIZE;
+		u32 rnd;
+
+		status = efi_get_random_bytes(sys_table, sizeof(rnd),
+					      (u8 *)&rnd);
+		if (status == EFI_SUCCESS) {
+			virtmap_base = EFI_RT_VIRTUAL_BASE +
+				       (((headroom >> 21) * rnd) >> (32 - 21));
+		}
+	}
+
 	new_fdt_addr = fdt_addr;
 	status = allocate_new_fdt_and_exit_boot(sys_table, handle,
 				&new_fdt_addr, efi_get_max_fdt_addr(dram_base),
@@ -242,18 +277,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 	return EFI_ERROR;
 }
 
-/*
- * This is the base address at which to start allocating virtual memory ranges
- * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
- * any allocation we choose, and eliminate the risk of a conflict after kexec.
- * The value chosen is the largest non-zero power of 2 suitable for this purpose
- * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
- * be mapped efficiently.
- * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
- * map everything below 1 GB.
- */
-#define EFI_RT_VIRTUAL_BASE	SZ_512M
-
 static int cmp_mem_desc(const void *l, const void *r)
 {
 	const efi_memory_desc_t *left = l, *right = r;
@@ -303,7 +326,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count)
 {
-	u64 efi_virt_base = EFI_RT_VIRTUAL_BASE;
+	u64 efi_virt_base = virtmap_base;
 	efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
 	int l;
 
-- 
2.9.3

[toc] | [next] | [standalone]

#1616726 — [tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-04-05 11:10 +0200
Subject[tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region
Message-ID<tsP6V-FR-15@gated-at.bofh.it>
In reply to#1616170
Commit-ID:  170bd898f1ae1ad717d56053846f8bbd2e526045
Gitweb:     http://git.kernel.org/tip/170bd898f1ae1ad717d56053846f8bbd2e526045
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Tue, 4 Apr 2017 17:09:10 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 5 Apr 2017 09:27:55 +0200

ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

Update the allocation logic for the virtual mapping of the UEFI runtime
services to start from a randomized base address if KASLR is in effect,
and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.

This makes it more difficult to predict the location of exploitable
data structures in the runtime UEFI firmware, which increases robustness
against attacks. Note that these regions are only mapped during the
time a runtime service call is in progress, and only on a single CPU
at a time, bit given the lack of a downside, let's enable it nonetheless.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bhe@redhat.com
Cc: bhsharma@redhat.com
Cc: eugene@hp.com
Cc: evgeny.kalugin@intel.com
Cc: jhugo@codeaurora.org
Cc: leif.lindholm@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: mark.rutland@arm.com
Cc: roy.franz@cavium.com
Cc: rruigrok@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 657bb72..1e45ec5 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,6 +18,22 @@
 
 #include "efistub.h"
 
+/*
+ * This is the base address at which to start allocating virtual memory ranges
+ * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
+ * any allocation we choose, and eliminate the risk of a conflict after kexec.
+ * The value chosen is the largest non-zero power of 2 suitable for this purpose
+ * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
+ * be mapped efficiently.
+ * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
+ * map everything below 1 GB. (512 MB is a reasonable upper bound for the
+ * entire footprint of the UEFI runtime services memory regions)
+ */
+#define EFI_RT_VIRTUAL_BASE	SZ_512M
+#define EFI_RT_VIRTUAL_SIZE	SZ_512M
+
+static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
+
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 			     void *__image, void **__fh)
 {
@@ -213,6 +229,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	efi_random_get_seed(sys_table);
 
+	if (!nokaslr()) {
+		/*
+		 * Randomize the base of the UEFI runtime services region.
+		 * Preserve the 2 MB alignment of the region by taking a
+		 * shift of 21 bit positions into account when scaling
+		 * the headroom value using a 32-bit random value.
+		 */
+		u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
+			       EFI_RT_VIRTUAL_SIZE;
+		u32 rnd;
+
+		status = efi_get_random_bytes(sys_table, sizeof(rnd),
+					      (u8 *)&rnd);
+		if (status == EFI_SUCCESS) {
+			virtmap_base = EFI_RT_VIRTUAL_BASE +
+				       (((headroom >> 21) * rnd) >> (32 - 21));
+		}
+	}
+
 	new_fdt_addr = fdt_addr;
 	status = allocate_new_fdt_and_exit_boot(sys_table, handle,
 				&new_fdt_addr, efi_get_max_fdt_addr(dram_base),
@@ -242,18 +277,6 @@ fail:
 	return EFI_ERROR;
 }
 
-/*
- * This is the base address at which to start allocating virtual memory ranges
- * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
- * any allocation we choose, and eliminate the risk of a conflict after kexec.
- * The value chosen is the largest non-zero power of 2 suitable for this purpose
- * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
- * be mapped efficiently.
- * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
- * map everything below 1 GB.
- */
-#define EFI_RT_VIRTUAL_BASE	SZ_512M
-
 static int cmp_mem_desc(const void *l, const void *r)
 {
 	const efi_memory_desc_t *left = l, *right = r;
@@ -303,7 +326,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count)
 {
-	u64 efi_virt_base = EFI_RT_VIRTUAL_BASE;
+	u64 efi_virt_base = virtmap_base;
 	efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
 	int l;

[toc] | [prev] | [next] | [standalone]

#1616822 — [tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

Fromtip-bot for Ard Biesheuvel <tipbot@zytor.com>
Date2017-04-05 12:50 +0200
Subject[tip:efi/core] ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region
Message-ID<tsQFH-1vp-7@gated-at.bofh.it>
In reply to#1616170
Commit-ID:  e69176d68d26d63d9214797c191ce65358ea1ecf
Gitweb:     http://git.kernel.org/tip/e69176d68d26d63d9214797c191ce65358ea1ecf
Author:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
AuthorDate: Tue, 4 Apr 2017 17:09:10 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 5 Apr 2017 12:27:29 +0200

ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region

Update the allocation logic for the virtual mapping of the UEFI runtime
services to start from a randomized base address if KASLR is in effect,
and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.

This makes it more difficult to predict the location of exploitable
data structures in the runtime UEFI firmware, which increases robustness
against attacks. Note that these regions are only mapped during the
time a runtime service call is in progress, and only on a single CPU
at a time, bit given the lack of a downside, let's enable it nonetheless.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bhe@redhat.com
Cc: bhsharma@redhat.com
Cc: eugene@hp.com
Cc: evgeny.kalugin@intel.com
Cc: jhugo@codeaurora.org
Cc: leif.lindholm@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: mark.rutland@arm.com
Cc: roy.franz@cavium.com
Cc: rruigrok@codeaurora.org
Link: http://lkml.kernel.org/r/20170404160910.28115-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
 1 file changed, 36 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 657bb72..1e45ec5 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,6 +18,22 @@
 
 #include "efistub.h"
 
+/*
+ * This is the base address at which to start allocating virtual memory ranges
+ * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
+ * any allocation we choose, and eliminate the risk of a conflict after kexec.
+ * The value chosen is the largest non-zero power of 2 suitable for this purpose
+ * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
+ * be mapped efficiently.
+ * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
+ * map everything below 1 GB. (512 MB is a reasonable upper bound for the
+ * entire footprint of the UEFI runtime services memory regions)
+ */
+#define EFI_RT_VIRTUAL_BASE	SZ_512M
+#define EFI_RT_VIRTUAL_SIZE	SZ_512M
+
+static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
+
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 			     void *__image, void **__fh)
 {
@@ -213,6 +229,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	efi_random_get_seed(sys_table);
 
+	if (!nokaslr()) {
+		/*
+		 * Randomize the base of the UEFI runtime services region.
+		 * Preserve the 2 MB alignment of the region by taking a
+		 * shift of 21 bit positions into account when scaling
+		 * the headroom value using a 32-bit random value.
+		 */
+		u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE -
+			       EFI_RT_VIRTUAL_SIZE;
+		u32 rnd;
+
+		status = efi_get_random_bytes(sys_table, sizeof(rnd),
+					      (u8 *)&rnd);
+		if (status == EFI_SUCCESS) {
+			virtmap_base = EFI_RT_VIRTUAL_BASE +
+				       (((headroom >> 21) * rnd) >> (32 - 21));
+		}
+	}
+
 	new_fdt_addr = fdt_addr;
 	status = allocate_new_fdt_and_exit_boot(sys_table, handle,
 				&new_fdt_addr, efi_get_max_fdt_addr(dram_base),
@@ -242,18 +277,6 @@ fail:
 	return EFI_ERROR;
 }
 
-/*
- * This is the base address at which to start allocating virtual memory ranges
- * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
- * any allocation we choose, and eliminate the risk of a conflict after kexec.
- * The value chosen is the largest non-zero power of 2 suitable for this purpose
- * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
- * be mapped efficiently.
- * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
- * map everything below 1 GB.
- */
-#define EFI_RT_VIRTUAL_BASE	SZ_512M
-
 static int cmp_mem_desc(const void *l, const void *r)
 {
 	const efi_memory_desc_t *left = l, *right = r;
@@ -303,7 +326,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count)
 {
-	u64 efi_virt_base = EFI_RT_VIRTUAL_BASE;
+	u64 efi_virt_base = virtmap_base;
 	efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
 	int l;

[toc] | [prev] | [next] | [standalone]

#1618925 — Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region

FromCatalin Marinas <catalin.marinas@arm.com>
Date2017-04-07 18:00 +0200
SubjectRe: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region
Message-ID<ttEsO-K9-9@gated-at.bofh.it>
In reply to#1616170
Hi Ard,

On 4 April 2017 at 17:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Update the allocation logic for the virtual mapping of the UEFI runtime
> services to start from a randomized base address if KASLR is in effect,
> and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
>
> This makes it more difficult to predict the location of exploitable
> data structures in the runtime UEFI firmware, which increases robustness
> against attacks. Note that these regions are only mapped during the
> time a runtime service call is in progress, and only on a single CPU
> at a time, bit give the lack of a downside, let's enable it nonetheless.
>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
>  1 file changed, 36 insertions(+), 13 deletions(-)

This patch causes a boot regression on Juno and Seattle (reported by
James Morse) with defconfig. On Juno I get a Synchronous Exception
(translation fault, second level). If I build the kernel with 64K
pages, it boots ok.

See below, though likely wrapped by gmail:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table

Synchronous Exception at 0x00000000F82A045C

 X0 0x0000000000000000 X1 0x00000000FDF01614 X2 0x7BF580F1AD8AE581 X3
0x0000000000000000
 X4 0x0000000000000000 X5 0x00000000FDFBFC60 X6 0x42F27CEB1CE1E5BC X7
0x7BF580F1AD8AE581
 X8 0x0000000000000000 X9 0x0000000700000000 X10 0x00000000FB5C0000
X11 0x00000000FB5C5FFF
 X12 0x0000000000000000 X13 0x000000000000000E X14 0x8000000000000001
X15 0x0000000000000000
 X16 0x00000000FEFFF5E0 X17 0x0000000000000000 X18 0x0000000000000000
X19 0x00000000FDFB0018
 X20 0x00000000F8390000 X21 0x00000000FB5BDA18 X22 0x00000000FEFFF5D0
X23 0x00000009FFFF0000
 X24 0x00000000FEFFF598 X25 0x0000000000000000 X26 0x0000000000000000
X27 0x0000000000000000
 X28 0x0000000000000000 FP 0x00000000FEFFF510 LR 0x00000000F82A0454

 V0 0xA4775AF0716632D7 DB7509796C96DACB V1 0xE67211106C932C4D 4F7141B24C78074F
 V2 0x550C7DC3243185BE 12835B01D807AA98 V3 0xC19BF1749BDC06A7 80DEB1FE72BE5D74
 V4 0x240CA1CC0FC19DC6 EFBE4786E49B69C1 V5 0x76F988DA5CB0A9DC 4A7484AA2DE92C6F
 V6 0xBF597FC7B00327C8 A831C66D983E5152 V7 0x1429296706CA6351 D5A79147C6E00BF3
 V8 0x0000000000000000 2E1B213827B70A85 V9 0x0000000000000000 766A0ABB650A7354
 V10 0x0000000000000000 A81A664BA2BFE8A1 V11 0x0000000000000000 D6990624D192E819
 V12 0x0000000000000000 1E376C0819A4C116 V13 0x0000000000000000 4ED8AA4A391C0CB3
 V14 0x0000000000000000 78A5636F748F82EE V15 0x0000000000000000 A4506CEB90BEFFFA
 V16 0x3C83709547545153 BC990E9F897D4FA8 V17 0xBEBEF297C5EC0578 E1D99AE8C2B92607
 V18 0x13242833C5F05BAB 101C24C521387481 V19 0x0A50ABCAD0BDDA12 996865483E880969
 V20 0x6C4ABAA53A9BE1CB 4416D9F479B08221 V21 0x60952147C3A68574 55B8AE51435C1A1A
 V22 0x9FEB2A3B4AB8D3BF 88C1883495C7F76F V23 0xD0C224BC8FB77E09 3DB8D233CF470963
 V24 0x0E72963E02D21C93 C95B757DA62B3A12 V25 0x2A77DBA1E4EE5D5C E08479A1B557DFA8
 V26 0xB593F86668CA8129 927A0019CDEC1A76 V27 0xFF03D7BC13D5FFF6 BBA1EFEF4B817FFA
 V28 0xE3FEE1F77F5FF733 5FBC3CE8E54BBB53 V29 0x4E8582114F72CE7E EED3F6BF4B0F5BDC
 V30 0xFFFA7FFBF72FF9F7 F8F06FDB9FF5EDEA V31 0xDE3785D1AEB3DAB7 12E08FF9AD0F87FF

 SP 0x00000000FEFFF500 ELR 0x00000000F82A045C SPSR 0x60000209 FPSR 0x00000000
 ESR 0x96000006 FAR 0x0000000000000000

 ESR : EC 0x25 IL 0x1 ISS 0x00000006

Data abort: Translation fault, second level

Stack dump:
 00000FEFFF400: 996865483E880969 0A50ABCAD0BDDA12 4416D9F479B08221
6C4ABAA53A9BE1CB
 00000FEFFF420: 55B8AE51435C1A1A 60952147C3A68574 88C1883495C7F76F
9FEB2A3B4AB8D3BF
 00000FEFFF440: 3DB8D233CF470963 D0C224BC8FB77E09 C95B757DA62B3A12
0E72963E02D21C93
 00000FEFFF460: E08479A1B557DFA8 2A77DBA1E4EE5D5C 927A0019CDEC1A76
B593F86668CA8129
 00000FEFFF480: BBA1EFEF4B817FFA FF03D7BC13D5FFF6 5FBC3CE8E54BBB53
E3FEE1F77F5FF733
 00000FEFFF4A0: EED3F6BF4B0F5BDC 4E8582114F72CE7E F8F06FDB9FF5EDEA
FFFA7FFBF72FF9F7
 00000FEFFF4C0: 12E08FF9AD0F87FF DE3785D1AEB3DAB7 00000000F82A045C
0000000060000209
 00000FEFFF4E0: 0000000000000000 0000000096000006 0000000000000000
7BF580F1AD8AE581
> 00000FEFFF500: 00000000FEFFF520 00000000FDFE1658 00000000FEFFF5C0 00000000F829D4CC
 00000FEFFF520: 00000000FB5C6040 00000000FCA74698 0000000000000000
0000000000000000
 00000FEFFF540: 0000000000000000 0000000000000000 00000000000000B0
000000F2F865A8B0
 00000FEFFF560: 00000000FB5C6040 0000000000000000 0000000000000000
00000000F86C0000
 00000FEFFF580: 000000000000503F 0000000080080000 0000000000F20000
0000000000000000
 00000FEFFF5A0: 11D295625B1B31A1 3B7269C9A0003F8E 4A3823DC9042A9DE
6A5180D0DE7AFB96
 00000FEFFF5C0: 00000000FEFFF5E0 00000000FDFD3AA8 0000000080080000
00000000FB5D6C18
 00000FEFFF5E0: 00000000FEFFF660 00000000F859C830 00000000F865A8B0
0000000000000000


Thanks,

Catalin

[toc] | [prev] | [next] | [standalone]

#1618927 — Re: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-04-07 18:10 +0200
SubjectRe: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region
Message-ID<ttECt-13t-1@gated-at.bofh.it>
In reply to#1618925
On 7 April 2017 at 16:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> Hi Ard,
>
> On 4 April 2017 at 17:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> Update the allocation logic for the virtual mapping of the UEFI runtime
>> services to start from a randomized base address if KASLR is in effect,
>> and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
>>
>> This makes it more difficult to predict the location of exploitable
>> data structures in the runtime UEFI firmware, which increases robustness
>> against attacks. Note that these regions are only mapped during the
>> time a runtime service call is in progress, and only on a single CPU
>> at a time, bit give the lack of a downside, let's enable it nonetheless.
>>
>> Cc: Ingo Molnar <mingo@kernel.org>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++---------
>>  1 file changed, 36 insertions(+), 13 deletions(-)
>
> This patch causes a boot regression on Juno and Seattle (reported by
> James Morse) with defconfig. On Juno I get a Synchronous Exception
> (translation fault, second level). If I build the kernel with 64K
> pages, it boots ok.
>
> See below, though likely wrapped by gmail:
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
>
> Synchronous Exception at 0x00000000F82A045C
>
>  X0 0x0000000000000000 X1 0x00000000FDF01614 X2 0x7BF580F1AD8AE581 X3
> 0x0000000000000000
>  X4 0x0000000000000000 X5 0x00000000FDFBFC60 X6 0x42F27CEB1CE1E5BC X7
> 0x7BF580F1AD8AE581
>  X8 0x0000000000000000 X9 0x0000000700000000 X10 0x00000000FB5C0000
> X11 0x00000000FB5C5FFF
>  X12 0x0000000000000000 X13 0x000000000000000E X14 0x8000000000000001
> X15 0x0000000000000000
>  X16 0x00000000FEFFF5E0 X17 0x0000000000000000 X18 0x0000000000000000
> X19 0x00000000FDFB0018
>  X20 0x00000000F8390000 X21 0x00000000FB5BDA18 X22 0x00000000FEFFF5D0
> X23 0x00000009FFFF0000
>  X24 0x00000000FEFFF598 X25 0x0000000000000000 X26 0x0000000000000000
> X27 0x0000000000000000
>  X28 0x0000000000000000 FP 0x00000000FEFFF510 LR 0x00000000F82A0454
>
>  V0 0xA4775AF0716632D7 DB7509796C96DACB V1 0xE67211106C932C4D 4F7141B24C78074F
>  V2 0x550C7DC3243185BE 12835B01D807AA98 V3 0xC19BF1749BDC06A7 80DEB1FE72BE5D74
>  V4 0x240CA1CC0FC19DC6 EFBE4786E49B69C1 V5 0x76F988DA5CB0A9DC 4A7484AA2DE92C6F
>  V6 0xBF597FC7B00327C8 A831C66D983E5152 V7 0x1429296706CA6351 D5A79147C6E00BF3
>  V8 0x0000000000000000 2E1B213827B70A85 V9 0x0000000000000000 766A0ABB650A7354
>  V10 0x0000000000000000 A81A664BA2BFE8A1 V11 0x0000000000000000 D6990624D192E819
>  V12 0x0000000000000000 1E376C0819A4C116 V13 0x0000000000000000 4ED8AA4A391C0CB3
>  V14 0x0000000000000000 78A5636F748F82EE V15 0x0000000000000000 A4506CEB90BEFFFA
>  V16 0x3C83709547545153 BC990E9F897D4FA8 V17 0xBEBEF297C5EC0578 E1D99AE8C2B92607
>  V18 0x13242833C5F05BAB 101C24C521387481 V19 0x0A50ABCAD0BDDA12 996865483E880969
>  V20 0x6C4ABAA53A9BE1CB 4416D9F479B08221 V21 0x60952147C3A68574 55B8AE51435C1A1A
>  V22 0x9FEB2A3B4AB8D3BF 88C1883495C7F76F V23 0xD0C224BC8FB77E09 3DB8D233CF470963
>  V24 0x0E72963E02D21C93 C95B757DA62B3A12 V25 0x2A77DBA1E4EE5D5C E08479A1B557DFA8
>  V26 0xB593F86668CA8129 927A0019CDEC1A76 V27 0xFF03D7BC13D5FFF6 BBA1EFEF4B817FFA
>  V28 0xE3FEE1F77F5FF733 5FBC3CE8E54BBB53 V29 0x4E8582114F72CE7E EED3F6BF4B0F5BDC
>  V30 0xFFFA7FFBF72FF9F7 F8F06FDB9FF5EDEA V31 0xDE3785D1AEB3DAB7 12E08FF9AD0F87FF
>
>  SP 0x00000000FEFFF500 ELR 0x00000000F82A045C SPSR 0x60000209 FPSR 0x00000000
>  ESR 0x96000006 FAR 0x0000000000000000
>
>  ESR : EC 0x25 IL 0x1 ISS 0x00000006
>
> Data abort: Translation fault, second level
>
> Stack dump:
>  00000FEFFF400: 996865483E880969 0A50ABCAD0BDDA12 4416D9F479B08221
> 6C4ABAA53A9BE1CB
>  00000FEFFF420: 55B8AE51435C1A1A 60952147C3A68574 88C1883495C7F76F
> 9FEB2A3B4AB8D3BF
>  00000FEFFF440: 3DB8D233CF470963 D0C224BC8FB77E09 C95B757DA62B3A12
> 0E72963E02D21C93
>  00000FEFFF460: E08479A1B557DFA8 2A77DBA1E4EE5D5C 927A0019CDEC1A76
> B593F86668CA8129
>  00000FEFFF480: BBA1EFEF4B817FFA FF03D7BC13D5FFF6 5FBC3CE8E54BBB53
> E3FEE1F77F5FF733
>  00000FEFFF4A0: EED3F6BF4B0F5BDC 4E8582114F72CE7E F8F06FDB9FF5EDEA
> FFFA7FFBF72FF9F7
>  00000FEFFF4C0: 12E08FF9AD0F87FF DE3785D1AEB3DAB7 00000000F82A045C
> 0000000060000209
>  00000FEFFF4E0: 0000000000000000 0000000096000006 0000000000000000
> 7BF580F1AD8AE581
>> 00000FEFFF500: 00000000FEFFF520 00000000FDFE1658 00000000FEFFF5C0 00000000F829D4CC
>  00000FEFFF520: 00000000FB5C6040 00000000FCA74698 0000000000000000
> 0000000000000000
>  00000FEFFF540: 0000000000000000 0000000000000000 00000000000000B0
> 000000F2F865A8B0
>  00000FEFFF560: 00000000FB5C6040 0000000000000000 0000000000000000
> 00000000F86C0000
>  00000FEFFF580: 000000000000503F 0000000080080000 0000000000F20000
> 0000000000000000
>  00000FEFFF5A0: 11D295625B1B31A1 3B7269C9A0003F8E 4A3823DC9042A9DE
> 6A5180D0DE7AFB96
>  00000FEFFF5C0: 00000000FEFFF5E0 00000000FDFD3AA8 0000000080080000
> 00000000FB5D6C18
>  00000FEFFF5E0: 00000000FEFFF660 00000000F859C830 00000000F865A8B0
> 0000000000000000
>

As I replied to James already, this is a bit surprising given the lack
of EFI_RNG_PROTOCOL in the AMI UEFI implementation. I will look into
it.

In the mean time, you can circumvent the issue by passing 'nokaslr' on
the kernel command line.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web