From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: linux-efi@vger.kernel.org, Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, "H . Peter Anvin" <hpa@zytor.com> Cc: matt@codeblueprint.co.uk, mark.rutland@arm.com, roy.franz@cavium.com, rruigrok@codeaurora.org, leif.lindholm@linaro.org, jhugo@codeaurora.org, evgeny.kalugin@intel.com, eugene@hp.com, bp@alien8.de, bhsharma@redhat.com, bhe@redhat.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-kernel@vger.kernel.org Subject: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Date: Tue, 4 Apr 2017 17:09:10 +0100 [thread overview] Message-ID: <20170404160910.28115-3-ard.biesheuvel@linaro.org> (raw) In-Reply-To: <20170404160910.28115-1-ard.biesheuvel@linaro.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, "H . Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> Cc: matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, roy.franz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org, rruigrok-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, jhugo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, evgeny.kalugin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, eugene-VXdhtT5mjnY@public.gmane.org, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org, bhsharma-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Date: Tue, 4 Apr 2017 17:09:10 +0100 [thread overview] Message-ID: <20170404160910.28115-3-ard.biesheuvel@linaro.org> (raw) In-Reply-To: <20170404160910.28115-1-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org> Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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
next prev parent reply other threads:[~2017-04-04 16:09 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-04 16:02 [GIT PULL 00/12] EFI updates for v4.12 Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 1/2] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 01/12] x86/efi: Clean up efi CR3 save/restore Ard Biesheuvel 2017-04-05 8:51 ` [tip:efi/core] x86/efi: Clean up the EFI CR3 save/restore logic tip-bot for Andy Lutomirski 2017-04-04 16:02 ` [PATCH 02/12] efi: arm-stub: Correct FDT and initrd allocation rules for arm64 Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:52 ` [tip:efi/core] efi/arm-stub: " tip-bot for Ard Biesheuvel 2017-04-05 10:33 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 03/12] efi: arm-stub: Round up FDT allocation to mapping size Ard Biesheuvel 2017-04-05 8:53 ` [tip:efi/core] efi/arm-stub: " tip-bot for Ard Biesheuvel 2017-04-05 10:34 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 04/12] x86/efi-bgrt: Move efi-bgrt handling out of arch/x86 Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:53 ` [tip:efi/core] x86/efi/bgrt: " tip-bot for Bhupesh Sharma 2017-04-05 10:34 ` tip-bot for Bhupesh Sharma 2017-04-04 16:02 ` [PATCH 05/12] efi: bgrt: Enable ACPI BGRT handling on arm64 Ard Biesheuvel 2017-04-05 8:54 ` [tip:efi/core] efi/bgrt: " tip-bot for Bhupesh Sharma 2017-04-05 10:35 ` tip-bot for Bhupesh Sharma 2017-04-04 16:02 ` [PATCH 06/12] pstore: return error code (if any) from efi_pstore_write Ard Biesheuvel 2017-04-05 8:54 ` [tip:efi/core] efi/pstore: Return error code (if any) from efi_pstore_write() tip-bot for Evgeny Kalugin 2017-04-05 10:35 ` tip-bot for Evgeny Kalugin 2017-04-04 16:02 ` [PATCH 07/12] x86/efi: Clean up a minor mistake in code comment Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:55 ` [tip:efi/core] x86/efi: Clean up a minor mistake in comment tip-bot for Baoquan He 2017-04-05 10:36 ` tip-bot for Baoquan He 2017-04-04 16:02 ` [PATCH 08/12] efi/arm32-stub: Allow boottime allocations in the vmlinux region Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:55 ` [tip:efi/core] efi/arm32-stub: Allow boot-time " tip-bot for Ard Biesheuvel 2017-04-05 10:36 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 09/12] efi/libstub: Fix harmless command line parsing bug Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:56 ` [tip:efi/core] " tip-bot for Ard Biesheuvel 2017-04-05 10:37 ` tip-bot for Ard Biesheuvel 2017-04-04 16:06 ` [GIT PULL 00/12] EFI updates for v4.12 Ard Biesheuvel 2017-04-04 16:09 ` [PATCH 10/12] efi/libstub: Unify command line param parsing Ard Biesheuvel 2017-04-04 16:09 ` Ard Biesheuvel 2017-04-04 16:09 ` [PATCH 11/12] efi/libstub: arm/arm64: Disable debug prints on 'quiet' cmdline arg Ard Biesheuvel 2017-04-05 8:57 ` [tip:efi/core] efi/libstub/arm/arm64: " tip-bot for Ard Biesheuvel 2017-04-05 10:38 ` tip-bot for Ard Biesheuvel 2017-04-11 4:08 ` [PATCH 11/12] efi/libstub: arm/arm64: " Jon Masters 2017-04-04 16:09 ` Ard Biesheuvel [this message] 2017-04-04 16:09 ` [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Ard Biesheuvel 2017-04-05 8:57 ` [tip:efi/core] ef/libstub/arm/arm64: " tip-bot for Ard Biesheuvel 2017-04-05 10:39 ` tip-bot for Ard Biesheuvel 2017-04-07 15:58 ` [PATCH 12/12] ef/libstub: arm/arm64: " Catalin Marinas 2017-04-07 15:58 ` Catalin Marinas 2017-04-07 16:02 ` Ard Biesheuvel 2017-04-07 16:02 ` Ard Biesheuvel 2017-04-05 8:56 ` [tip:efi/core] efi/libstub: Unify command line param parsing tip-bot for Ard Biesheuvel 2017-04-05 10:38 ` tip-bot for Ard Biesheuvel
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=20170404160910.28115-3-ard.biesheuvel@linaro.org \ --to=ard.biesheuvel@linaro.org \ --cc=bhe@redhat.com \ --cc=bhsharma@redhat.com \ --cc=bp@alien8.de \ --cc=eugene@hp.com \ --cc=evgeny.kalugin@intel.com \ --cc=hpa@zytor.com \ --cc=jhugo@codeaurora.org \ --cc=leif.lindholm@linaro.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=matt@codeblueprint.co.uk \ --cc=mingo@kernel.org \ --cc=roy.franz@cavium.com \ --cc=rruigrok@codeaurora.org \ --cc=tglx@linutronix.de \ /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: linkBe 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.