diff mbox series

[4/4] ef/libstub: arm/arm64: randomize the base of the UEFI rt services region

Message ID 20170324132410.16628-5-ard.biesheuvel@linaro.org
State Superseded
Headers show
Series efi: libstub enhancements for cmdline parsing and kaslr | expand

Commit Message

Ard Biesheuvel March 24, 2017, 1:24 p.m. UTC 
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 | 48 ++++++++++++++------
 1 file changed, 35 insertions(+), 13 deletions(-)

-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

James Morse April 7, 2017, 3:47 p.m. UTC | #1 
Hi Ard,

On 24/03/17 13:24, Ard Biesheuvel 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.


With next-20170407 on Seattle Overdrive, I get an SError[0] on boot:

The three patches I have on top of 4.11.0-rc5-next-20170407 are:
* Revert "efi/libstub/arm*: Set default address and size cells values for an
empty dtb"
* Revert "ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region"

At which point the machine start booting to a prompt again, (its noisier than
usual but looks like double-printing).

If I then cherry-pick:
* ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region"

It again fails, producing the trace below. This is all with next-20170407's
defconfig, 4K/48. UEFI identifies itself as:
> UEFI v2.40 (American Megatrends, 0x0005000B)



Thanks,

James


[0]
Shell> efi\morse\Image console=ttyAMA0,115200 root=PARTUUID=b2edf709-3b28-4cb3-8
809-203f262e2bcc rw earlycon=pl011,0xe1010000 crashkernel=1G stacktrace ignore_l
oglevel=1 acpi=on efi=debug resume=/dev/sda3
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.11.0-rc5-next-20170407-00003-gbe65d54f8671 (morse
@melchizedek) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11) ) #7
401 SMP PREEMPT Fri Apr 7 16:19:28 BST 2017
[    0.000000] Boot CPU: AArch64 Processor [411fd072]
[    0.000000] earlycon: pl11 at MMIO 0x00000000e1010000 (options '')
[    0.000000] bootconsole [pl11] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Bad mode in Error handler detected on CPU0, code 0xbf000000 -- SError
[    0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-rc5-next-20170407-
00003-gbe65d54f8671 #7401
[    0.000000] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive)
 (DT)
[    0.000000] task: ffff000008e02b80 task.stack: ffff000008df0000
[    0.000000] PC is at setup_arch+0xf0/0x504
[    0.000000] LR is at setup_arch+0xec/0x504
[    0.000000] pc : [<ffff000008ce2844>] lr : [<ffff000008ce2840>] pstate: 000000c5

[    0.000000] Call trace:
[    0.000000] [<ffff000008ce2844>] setup_arch+0xf0/0x504
[    0.000000] [<ffff000008ce0838>] start_kernel+0x70/0x398
[    0.000000] [<ffff000008ce01e0>] __primary_switched+0x64/0x74
[    0.000000] Code: 9111c000 940034d9 97fff7cd d50344ff (90fffce3)
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel April 7, 2017, 3:51 p.m. UTC | #2 
On 7 April 2017 at 16:47, James Morse <james.morse@arm.com> wrote:
> Hi Ard,

>

> On 24/03/17 13:24, Ard Biesheuvel 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.

>

> With next-20170407 on Seattle Overdrive, I get an SError[0] on boot:

>

> The three patches I have on top of 4.11.0-rc5-next-20170407 are:

> * Revert "efi/libstub/arm*: Set default address and size cells values for an

> empty dtb"

> * Revert "ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region"

>

> At which point the machine start booting to a prompt again, (its noisier than

> usual but looks like double-printing).

>

> If I then cherry-pick:

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

>


That is quite interesting, to be honest, because that patch should
effectively be a NOP on systems that do not implement
EFI_RNG_PROTOCOL.

Could you run this from the UEFI shell please?

http://people.linaro.org/~ard.biesheuvel/RngTest.efi

I would expect it to report that it has no EFI_RNG_PROTOCOL
implementation. Could you also check whether the working kernel still
works /after/ having executed that utility?


> It again fails, producing the trace below. This is all with next-20170407's

> defconfig, 4K/48. UEFI identifies itself as:

>> UEFI v2.40 (American Megatrends, 0x0005000B)

>

>

> Thanks,

>

> James

>

>

> [0]

> Shell> efi\morse\Image console=ttyAMA0,115200 root=PARTUUID=b2edf709-3b28-4cb3-8

> 809-203f262e2bcc rw earlycon=pl011,0xe1010000 crashkernel=1G stacktrace ignore_l

> oglevel=1 acpi=on efi=debug resume=/dev/sda3

> EFI stub: Booting Linux Kernel...

> EFI stub: Using DTB from configuration table

> EFI stub: Exiting boot services and installing virtual address map...

> [    0.000000] Booting Linux on physical CPU 0x0

> [    0.000000] Linux version 4.11.0-rc5-next-20170407-00003-gbe65d54f8671 (morse

> @melchizedek) (gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 2014.11) ) #7

> 401 SMP PREEMPT Fri Apr 7 16:19:28 BST 2017

> [    0.000000] Boot CPU: AArch64 Processor [411fd072]

> [    0.000000] earlycon: pl11 at MMIO 0x00000000e1010000 (options '')

> [    0.000000] bootconsole [pl11] enabled

> [    0.000000] debug: ignoring loglevel setting.

> [    0.000000] Bad mode in Error handler detected on CPU0, code 0xbf000000 -- SError

> [    0.000000] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP

> [    0.000000] Modules linked in:

> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-rc5-next-20170407-

> 00003-gbe65d54f8671 #7401

> [    0.000000] Hardware name: AMD Seattle (Rev.B0) Development Board (Overdrive)

>  (DT)

> [    0.000000] task: ffff000008e02b80 task.stack: ffff000008df0000

> [    0.000000] PC is at setup_arch+0xf0/0x504

> [    0.000000] LR is at setup_arch+0xec/0x504

> [    0.000000] pc : [<ffff000008ce2844>] lr : [<ffff000008ce2840>] pstate: 000000c5

>

> [    0.000000] Call trace:

> [    0.000000] [<ffff000008ce2844>] setup_arch+0xf0/0x504

> [    0.000000] [<ffff000008ce0838>] start_kernel+0x70/0x398

> [    0.000000] [<ffff000008ce01e0>] __primary_switched+0x64/0x74

> [    0.000000] Code: 9111c000 940034d9 97fff7cd d50344ff (90fffce3)

> [    0.000000] ---[ end trace 0000000000000000 ]---

> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

> [    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

>

> --

> To unsubscribe from this list: send the line "unsubscribe linux-efi" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Morse April 7, 2017, 4:11 p.m. UTC | #3 
Hi Ard,

On 07/04/17 16:51, Ard Biesheuvel wrote:
> That is quite interesting, to be honest, because that patch should

> effectively be a NOP on systems that do not implement

> EFI_RNG_PROTOCOL.

> 

> Could you run this from the UEFI shell please?

> 

> http://people.linaro.org/~ard.biesheuvel/RngTest.efi


As you predicted:

Shell> RngTest.efi
UEFI RNG Protocol Testing :
----------------------------
 -- Locate UEFI RNG Protocol : [Fail - Status = Not Found]
Error reported: Not Found


> I would expect it to report that it has no EFI_RNG_PROTOCOL

> implementation. Could you also check whether the working kernel still

> works /after/ having executed that utility?


The broken kernel remains broken after running that test. reboot. The working
kernel continues to work after running that test.

(On Monday) I will try with just these efi changes on v4.11-rc. to try and
eliminate everything else in linux-next.

This is one of those firmware versions that prints lots of
> efi: [Firmware Bug]: IRQ flags corrupted (0x00000140=>0x00000100) by EFI

get_variable


Thanks,

James

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Rutland April 10, 2017, 9:41 a.m. UTC | #4 
On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote:
> On 7 April 2017 at 16:47, James Morse <james.morse@arm.com> wrote:

> > On 24/03/17 13:24, Ard Biesheuvel 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.

> >

> > With next-20170407 on Seattle Overdrive, I get an SError[0] on boot:


> > * Revert "ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region"

> >

> > At which point the machine start booting to a prompt again, (its noisier than

> > usual but looks like double-printing).


> That is quite interesting, to be honest, because that patch should

> effectively be a NOP on systems that do not implement

> EFI_RNG_PROTOCOL.


FWIW, I'm also seeing a crash as a result of this patch, on a Juno R1
with an EFI_RNG_PROTOCOL implementation, with next-20170410 defconfig.
I'm using the Linaro 15.08 toolchain.

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


WARNING: this system is using an unsafe pseudo-random implementation of
RngLib!



Synchronous Exception at 0x00000000F80FC7E8
----

If I replace the !nokaslr() in efi_entry() with false, my kernel boots.

If I replace !nokaslr() with true, it fails to boot, even with the call
to efi_get_random_bytes() replaced with status = EFI_ERROR.

The problem appears to be the use of TASK_SIZE, since on arm64 that's:

#define TASK_SIZE               (test_thread_flag(TIF_32BIT) ? \
                                TASK_SIZE_32 : TASK_SIZE_64)

... which would mean that the stub would be trying to dereference whatever it
found in sp_el0. Looking at objdump:

0000000000000160 <efi_entry>:
 ...
 4b4:   94000000        bl      0 <nokaslr>
 4b8:   35000280        cbnz    w0, 508 <efi_entry+0x3a8>
 4bc:   d5384100        mrs     x0, sp_el0
 4c0:   f9400004        ldr     x4, [x0]
...

So I think we should revert this for now.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel April 10, 2017, 9:44 a.m. UTC | #5 
On 10 April 2017 at 10:41, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote:

>> On 7 April 2017 at 16:47, James Morse <james.morse@arm.com> wrote:

>> > On 24/03/17 13:24, Ard Biesheuvel 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.

>> >

>> > With next-20170407 on Seattle Overdrive, I get an SError[0] on boot:

>

>> > * Revert "ef/libstub/arm/arm64: Randomize the base of the UEFI rt services region"

>> >

>> > At which point the machine start booting to a prompt again, (its noisier than

>> > usual but looks like double-printing).

>

>> That is quite interesting, to be honest, because that patch should

>> effectively be a NOP on systems that do not implement

>> EFI_RNG_PROTOCOL.

>

> FWIW, I'm also seeing a crash as a result of this patch, on a Juno R1

> with an EFI_RNG_PROTOCOL implementation, with next-20170410 defconfig.

> I'm using the Linaro 15.08 toolchain.

>

> ----

> EFI stub: Booting Linux Kernel...

> EFI stub: Using DTB from configuration table

>

>

> WARNING: this system is using an unsafe pseudo-random implementation of

> RngLib!

>

>

>

> Synchronous Exception at 0x00000000F80FC7E8

> ----

>

> If I replace the !nokaslr() in efi_entry() with false, my kernel boots.

>

> If I replace !nokaslr() with true, it fails to boot, even with the call

> to efi_get_random_bytes() replaced with status = EFI_ERROR.

>

> The problem appears to be the use of TASK_SIZE, since on arm64 that's:

>

> #define TASK_SIZE               (test_thread_flag(TIF_32BIT) ? \

>                                 TASK_SIZE_32 : TASK_SIZE_64)

>

> ... which would mean that the stub would be trying to dereference whatever it

> found in sp_el0. Looking at objdump:

>

> 0000000000000160 <efi_entry>:

>  ...

>  4b4:   94000000        bl      0 <nokaslr>

>  4b8:   35000280        cbnz    w0, 508 <efi_entry+0x3a8>

>  4bc:   d5384100        mrs     x0, sp_el0

>  4c0:   f9400004        ldr     x4, [x0]

> ...

>

> So I think we should revert this for now.

>


Thanks for debugging this! I will get a fixed version out asap
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox series

Patch

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 6f522e3091af..eb5225884098 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 efi_virt_base = EFI_RT_VIRTUAL_BASE;
+
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg,
 			     void *__image, void **__fh)
 {
@@ -209,6 +225,25 @@  unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	efi_random_get_seed(sys_table);
 
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && !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) {
+			efi_virt_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),
@@ -238,18 +273,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;
@@ -299,7 +322,6 @@  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;
 	efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
 	int l;