Skip to content

Commit f9c4ff2

Browse files
Barry Songwilldeacon
authored andcommitted
arm64: fix the doc of RANDOMIZE_MODULE_REGION_FULL
Obviously kaslr is setting the module region to 2GB rather than 4GB since commit b2eed9b ("arm64/kernel: kaslr: reduce module randomization range to 2 GB"). So fix the size of region in Kconfig. On the other hand, even though RANDOMIZE_MODULE_REGION_FULL is not set, module_alloc() can fall back to a 2GB window if ARM64_MODULE_PLTS is set. In this case, veneers are still needed. !RANDOMIZE_MODULE_REGION_FULL doesn't necessarily mean veneers are not needed. So fix the doc to be more precise to avoid any confusion to the readers of the code. Cc: Masami Hiramatsu <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Qi Liu <[email protected]> Signed-off-by: Barry Song <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
1 parent 64ee84c commit f9c4ff2

File tree

2 files changed

+9
-4
lines changed

2 files changed

+9
-4
lines changed

arch/arm64/Kconfig

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1800,19 +1800,22 @@ config RANDOMIZE_BASE
18001800
If unsure, say N.
18011801

18021802
config RANDOMIZE_MODULE_REGION_FULL
1803-
bool "Randomize the module region over a 4 GB range"
1803+
bool "Randomize the module region over a 2 GB range"
18041804
depends on RANDOMIZE_BASE
18051805
default y
18061806
help
1807-
Randomizes the location of the module region inside a 4 GB window
1807+
Randomizes the location of the module region inside a 2 GB window
18081808
covering the core kernel. This way, it is less likely for modules
18091809
to leak information about the location of core kernel data structures
18101810
but it does imply that function calls between modules and the core
18111811
kernel will need to be resolved via veneers in the module PLT.
18121812

18131813
When this option is not set, the module region will be randomized over
18141814
a limited range that contains the [_stext, _etext] interval of the
1815-
core kernel, so branch relocations are always in range.
1815+
core kernel, so branch relocations are almost always in range unless
1816+
ARM64_MODULE_PLTS is enabled and the region is exhausted. In this
1817+
particular case of region exhaustion, modules might be able to fall
1818+
back to a larger 2GB area.
18161819

18171820
config CC_HAVE_STACKPROTECTOR_SYSREG
18181821
def_bool $(cc-option,-mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=0)

arch/arm64/kernel/kaslr.c

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -162,7 +162,9 @@ u64 __init kaslr_early_init(void)
162162
* a PAGE_SIZE multiple in the range [_etext - MODULES_VSIZE,
163163
* _stext) . This guarantees that the resulting region still
164164
* covers [_stext, _etext], and that all relative branches can
165-
* be resolved without veneers.
165+
* be resolved without veneers unless this region is exhausted
166+
* and we fall back to a larger 2GB window in module_alloc()
167+
* when ARM64_MODULE_PLTS is enabled.
166168
*/
167169
module_range = MODULES_VSIZE - (u64)(_etext - _stext);
168170
module_alloc_base = (u64)_etext + offset - MODULES_VSIZE;

0 commit comments

Comments
 (0)