LKML Archive on
help / color / mirror / Atom feed
* [PATCH] arm64/kernel: kaslr: reduce module randomization range to 2 GB
@ 2019-05-23  9:17 Ard Biesheuvel
  0 siblings, 0 replies; only message in thread
From: Ard Biesheuvel @ 2019-05-23  9:17 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: marc.zyngier, james.morse, will.deacon, guillaume.gardet,
	mark.rutland, linux-kernel, Ard Biesheuvel

The following commit

  7290d5809571 ("module: use relative references for __ksymtab entries")

updated the ksymtab handling of some KASLR capable architectures
so that ksymtab entries are emitted as pairs of 32-bit relative
references. This reduces the size of the entries, but more
importantly, it gets rid of statically assigned absolute
addresses, which require fixing up at boot time if the kernel
is self relocating (which takes a 24 byte RELA entry for each
member of the ksymtab struct).

Since ksymtab entries are always part of the same module as the
symbol they export, it was assumed at the time that a 32-bit
relative reference is always sufficient to capture the offset
between a ksymtab entry and its target symbol.

Unfortunately, this is not always true: in the case of per-CPU
variables, a per-CPU variable's base address (which usually differs
from the actual address of any of its per-CPU copies) is allocated
in the vicinity of the section in the core kernel
(i.e., in the per-CPU reserved region which follows the section
containing the core kernel's statically allocated per-CPU variables).

Since we randomize the module space over a 4 GB window covering
the core kernel (based on the -/+ 4 GB range of an ADRP/ADD pair),
we may end up putting the core kernel out of the -/+ 2 GB range of
32-bit relative references of module ksymtab entries that refer to
per-CPU variables.

So reduce the module randomization range a bit further. We lose
1 bit of randomization this way, but this is something we can

Cc: <> # v4.19+
Signed-off-by: Ard Biesheuvel <>

This supersedes

module/ksymtab: use 64-bit relative reference for target symbol
x86/tools: deal with 64-bit relative relocations for per-CPU symbols

and is complemented by

arm64/module: deal with ambiguity in PRELxx relocation ranges

 arch/arm64/kernel/kaslr.c  | 4 ++--
 arch/arm64/kernel/module.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b09b6f75f759..5d5f3ed3e66a 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -152,8 +152,8 @@ u64 __init kaslr_early_init(u64 dt_phys)
 		 * resolved via PLTs. (Branches between modules will be
 		 * resolved normally.)
-		module_range = SZ_4G - (u64)(_end - _stext);
-		module_alloc_base = max((u64)_end + offset - SZ_4G,
+		module_range = SZ_2G - (u64)(_end - _stext);
+		module_alloc_base = max((u64)_end + offset - SZ_2G,
 	} else {
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 2e4e3915b4d0..b2f99ff76ed1 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -56,7 +56,7 @@ void *module_alloc(unsigned long size)
 		 * can simply omit this fallback in that case.
 		p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
-				module_alloc_base + SZ_4G, GFP_KERNEL,
+				module_alloc_base + SZ_2G, GFP_KERNEL,

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-05-23  9:17 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-23  9:17 [PATCH] arm64/kernel: kaslr: reduce module randomization range to 2 GB Ard Biesheuvel

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).