From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] arm64: kaslr: increase randomization granularity
Date: Mon, 18 Apr 2016 17:09:48 +0200 [thread overview]
Message-ID: <1460992188-23295-9-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1460992188-23295-1-git-send-email-ard.biesheuvel@linaro.org>
Currently, our KASLR implementation randomizes the placement of the core
kernel at 2 MB granularity. This is based on the arm64 kernel boot
protocol, which mandates that the kernel is loaded TEXT_OFFSET bytes above
a 2 MB aligned base address. This requirement is a result of the fact that
the block size used by the early mapping code may be 2 MB at the most (for
a 4 KB granule kernel)
But we can do better than that: since a KASLR kernel needs to be relocated
in any case, we can tolerate a physical misalignment as long as the virtual
misalignment relative to this 2 MB block size is equal in size, and code to
deal with this is already in place.
Since we align the kernel segments to 64 KB, let's randomize the physical
offset at 64 KB granularity as well (unless CONFIG_DEBUG_ALIGN_RODATA is
enabled). This way, the page table and TLB footprint is not affected.
The higher granularity allows for 5 bits of additional entropy to be used.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm64-stub.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index a90f6459f5c6..eae693eb3e91 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -81,15 +81,24 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && phys_seed != 0) {
/*
+ * If CONFIG_DEBUG_ALIGN_RODATA is not set, produce a
+ * displacement in the interval [0, MIN_KIMG_ALIGN) that
+ * is a multiple of the minimal segment alignment (SZ_64K)
+ */
+ u32 mask = (MIN_KIMG_ALIGN - 1) & ~(SZ_64K - 1);
+ u32 offset = !IS_ENABLED(CONFIG_DEBUG_ALIGN_RODATA) ?
+ (phys_seed >> 32) & mask : TEXT_OFFSET;
+
+ /*
* If KASLR is enabled, and we have some randomness available,
* locate the kernel at a randomized offset in physical memory.
*/
- *reserve_size = kernel_memsize + TEXT_OFFSET;
+ *reserve_size = kernel_memsize + offset;
status = efi_random_alloc(sys_table_arg, *reserve_size,
MIN_KIMG_ALIGN, reserve_addr,
- phys_seed);
+ (u32)phys_seed);
- *image_addr = *reserve_addr + TEXT_OFFSET;
+ *image_addr = *reserve_addr + offset;
} else {
/*
* Else, try a straight allocation at the preferred offset.
--
2.5.0
next prev parent reply other threads:[~2016-04-18 15:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 15:09 [PATCH 0/8] arm64: kaslr cleanups and improvements Ard Biesheuvel
2016-04-18 15:09 ` [PATCH 1/8] arm64: kernel: don't export local symbols from head.S Ard Biesheuvel
2016-04-18 15:35 ` Mark Rutland
2016-04-18 15:09 ` [PATCH 2/8] arm64: kernel: use literal for relocated address of __secondary_switched Ard Biesheuvel
2016-04-18 15:57 ` Mark Rutland
2016-04-18 15:09 ` [PATCH 3/8] arm64: kernel: perform relocation processing from ID map Ard Biesheuvel
2016-04-18 15:09 ` [PATCH 4/8] arm64: introduce mov_q macro to move a constant into a 64-bit register Ard Biesheuvel
2016-04-18 15:09 ` [PATCH 5/8] arm64: kernel: replace early 64-bit literal loads with move-immediates Ard Biesheuvel
2016-04-19 14:29 ` Laurentiu Tudor
2016-04-18 15:09 ` [PATCH 6/8] arm64: don't map TEXT_OFFSET bytes below the kernel if we can avoid it Ard Biesheuvel
2016-04-18 15:09 ` [PATCH 7/8] arm64: relocatable: deal with physically misaligned kernel images Ard Biesheuvel
2016-04-18 15:09 ` Ard Biesheuvel [this message]
2016-04-26 11:27 ` [PATCH 8/8] arm64: kaslr: increase randomization granularity Will Deacon
2016-04-26 15:27 ` Matt Fleming
2016-04-25 16:38 ` [PATCH 0/8] arm64: kaslr cleanups and improvements Catalin Marinas
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=1460992188-23295-9-git-send-email-ard.biesheuvel@linaro.org \
--to=ard.biesheuvel@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).