You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
arch: make every module band cover its configurations
The band is a validation union: its floor must sit at or below the module
region under every configuration the header models, or module addresses
are discarded before they become observations — silently, since
proc_modules then reports "no kernel address found", the same as an empty
file. Auditing all seven candidate arches found two floors that did not.
x86_64: MODULES_VADDR is __START_KERNEL_map + KERNEL_IMAGE_SIZE, and that
size is 1 GiB only with CONFIG_RANDOMIZE_BASE; a kernel built without it
puts modules at 0xffffffffa0000000, half a gigabyte below the old floor.
Build-time, so booting nokaslr does not reproduce it and the nokaslr VM
cells never caught it. sidt.c had to stop reading MODULES_START as its
kernel-text ceiling, which it could while the two coincided.
ppc64: 64-bit PowerPC has no MODULES_VADDR, so modules come from vmalloc,
whose base spans 32 TiB across MMU configurations — 0xc008000000000000 for
radix and 64k-page hash, but 0xc0003d0000000000 for 4k-page hash and
0xc000100000000000 for Book3E. The floor is now the lowest.
loongarch64: vm_map_base is 0 - (1 << cpu_vabits), read from CPUCFG1, so a
wider VA moves the region down. Shipping parts report 39 and 48, but the
kernel's page tables reach 58 bits, so the floor is anchored there rather
than on the widest part that happens to exist.
riscv64, s390, mips32 and mips64 already held and are declared as-is.
With the bands exact, module_base_execmem_window confines Q_MODULE_BASE to
execmem_arch_setup()'s own window: start = MODULES_VADDR + rand(1,1024) *
PAGE_SIZE, about 10 bits drawn independently of the text slide. It is gated
on evidence the image moved, which proves RANDOMIZE_BASE=y and so fixes
which MODULES_VADDR is live; without that the window could be in the wrong
place entirely, so the rule stays silent. Offset 0 stays in range because
RANDOMIZE_MEMORY depends on RANDOMIZE_BASE.
x86_64 Module Region Base goes from unbounded to 1025 candidates. Doc
samples re-captured from the same mainline 7.0 boot under KVM.
0 commit comments