[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