[PATCH v3 0/6] arm64: module: improve module VA range selection
Shanker Donthineni
sdonthineni at nvidia.com
Sat Jun 3 01:56:22 PDT 2023
Hi Mark,
I've reviewed and verified on NVIDIA server platforms w/ and w/o KASLR feature is disabled.
root at localhost:~# dmesg | grep -E "Modules:|KASLR"
[ 0.000000] KASLR disabled on command line
[ 5.961360] Modules: 1223 pages in range for non-PLT usage
[ 5.961362] Modules: 31943 pages in range for PLT usage
Looks good to me.
Tested-by: Shanker Donthineni <sdonthineni at nvidia.com>
On 5/30/23 06:03, Mark Rutland wrote:
> External email: Use caution opening links or attachments
>
>
> This series (based on v6.4-rc3) aims to make arm64's module allocation
> code more robust. To that end:
>
> * Redundant code for KASAN && !KASAN_VMALLOC is removed, as this
> combination is no longer possible.
>
> * Module PLT support is mandated, always allowing for the use of a 2G
> module region. Practically speaking, this is already the case for almost
> all users as module PLT support is mandated by both KASLR (which most
> distros including Android, enable this), and by the workaround for ARM
> erratum 843419 (required by Cortex-A53).
>
> * The module VA region selection is moved to module.c, making it
> self-contained and easier to follow.
>
> * The default module VA region is expanded to 2G. This ensures that
> there is sufficient space for the full region using PLTs even when
> KASLR is disabled or no seed provided.
>
> * The module VA range init code is updated to log when the kernel is too
> large to support the use of a 128M or 2G module region, to enable
> debugging of these cases. Contemporary kernels built with debug
> options can be bigger than 128M, and a kernel bigger than 2G is
> unlikely but theoretically possible. Adding this logging should help
> to debug or filter away reports for such cases.
>
> This should allow for loading of very large modules, as Shanker reported
> was an issue:
>
> https://lore.kernel.org/linux-arm-kernel/20230326170756.3021936-1-sdonthineni@nvidia.com/
> https://lore.kernel.org/linux-arm-kernel/20230330140437.984211-1-sdonthineni@nvidia.com/
>
> ... and as Ard had an alternative series for:
>
> https://lore.kernel.org/linux-arm-kernel/20230404135437.2744866-1-ardb@kernel.org/
>
> Since v1 [1]:
> * Log the number of pages in range
> * Remove unused kasan_mod_shadow_end
> * Only randomize when kaslr_enabled()
> * Simplify control-flow
>
> Since v2 [2]:
> * Apply Ard's Reviewed-by tags
> * Fix typos
> * Rebave to v6.4-rc3 (trivial)
>
> [1] https://lore.kernel.org/linux-arm-kernel/20230509111451.4184972-1-mark.rutland@arm.com/
> [2] https://lore.kernel.org/linux-arm-kernel/20230512152210.3072475-1-mark.rutland@arm.com/
>
> Thanks,
> Mark.
>
> Mark Rutland (6):
> arm64: module: remove old !KASAN_VMALLOC logic
> arm64: kasan: remove !KASAN_VMALLOC remnants
> arm64: kaslr: split kaslr/module initialization
> arm64: module: move module randomization to module.c
> arm64: module: mandate MODULE_PLTS
> arm64: module: rework module VA range selection
>
> Documentation/arm64/memory.rst | 8 +-
> arch/arm64/Kconfig | 28 +----
> arch/arm64/include/asm/memory.h | 16 +--
> arch/arm64/include/asm/module.h | 8 --
> arch/arm64/include/asm/module.lds.h | 2 -
> arch/arm64/kernel/Makefile | 3 +-
> arch/arm64/kernel/ftrace.c | 8 +-
> arch/arm64/kernel/kaslr.c | 83 +++------------
> arch/arm64/kernel/module.c | 159 +++++++++++++++++++++-------
> arch/arm64/kernel/setup.c | 2 +
> arch/arm64/mm/kasan_init.c | 17 +--
> 11 files changed, 159 insertions(+), 175 deletions(-)
>
> --
> 2.30.2
>
More information about the linux-arm-kernel
mailing list