Re: [PATCH v2 3/6] arm64: kaslr: split kaslr/module initialization

Re: [PATCH v2 3/6] arm64: kaslr: split kaslr/module initialization

[Ard Biesheuvel]

On Fri, 12 May 2023 at 17:22, Mark Rutland <mark.rutland@arm.com> wrote:
>
> Currently kaslr_init() handles a mixture of detecting/announcing whether
> KASLR is enabled, and randomizing the module region depening on whether
> KASLR is enabled.
>
> To make it easier to rework the module region initialization, split the
> KASLR initialization into two steps:
>
> * kaslr_init() determines whether KASLR should be enabled, and announces
>   this choice, recoding this to a new global boolean variable. This is
>   called from setup_arch() just before the existing call to
>   kaslr_requires_kpti() so that this will always provide the expected
>   result.
>
> * kaslr_module_init() randomizes the module region when required. This
>   is called as a syubsys_initcall, where we previosuly called

subsys_initcall

>   kaslr_init().
>
> As a bomus, moving the KASLR reporting earlier makes it easier to spot

bonus

> and permits it to be logged via earlycon, making it easier to debug any
> issues that could be triggerer by KASLR.

triggered

>
> Booting a v6.4-rc1 kernel with this patch applied, the log looks like:
>
> | EFI stub: Booting Linux Kernel...
> | EFI stub: Generating empty DTB
> | EFI stub: Exiting boot services...
> | [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
> | [    0.000000] Linux version 6.4.0-rc1-00006-g4763a8f8aeb3 (mark@lakrids) (aarch64-linux-gcc (GCC) 12.1.0, GNU ld (GNU Binutils) 2.38) #2 SMP PREEMPT Tue May  9 11:03:37 BST 2023
> | [    0.000000] KASLR enabled
> | [    0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')
> | [    0.000000] printk: bootconsole [pl11] enabled
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
>  arch/arm64/include/asm/memory.h | 14 +++++++-----
>  arch/arm64/kernel/kaslr.c       | 39 +++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c       |  2 ++
>  3 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index c735afdf639b..215efc3bbbcf 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -204,15 +204,17 @@ static inline unsigned long kaslr_offset(void)
>         return kimage_vaddr - KIMAGE_VADDR;
>  }
>
> +#ifdef CONFIG_RANDOMIZE_BASE
> +void kaslr_init(void);
>  static inline bool kaslr_enabled(void)
>  {
> -       /*
> -        * The KASLR offset modulo MIN_KIMG_ALIGN is taken from the physical
> -        * placement of the image rather than from the seed, so a displacement
> -        * of less than MIN_KIMG_ALIGN means that no seed was provided.
> -        */
> -       return kaslr_offset() >= MIN_KIMG_ALIGN;
> +       extern bool __kaslr_is_enabled;
> +       return __kaslr_is_enabled;
>  }
> +#else
> +static inline void kaslr_init(void) { }
> +static inline bool kaslr_enabled(void) { return false; }
> +#endif
>
>  /*
>   * Allow all memory at the discovery stage. We will clip it later.
> diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
> index df433c80c6ef..ce7079ba1dc1 100644
> --- a/arch/arm64/kernel/kaslr.c
> +++ b/arch/arm64/kernel/kaslr.c
> @@ -25,28 +25,39 @@ u16 __initdata memstart_offset_seed;
>
>  struct arm64_ftr_override kaslr_feature_override __initdata;
>
> -static int __init kaslr_init(void)
> -{
> -       u64 module_range;
> -       u32 seed;
> -
> -       /*
> -        * Set a reasonable default for module_alloc_base in case
> -        * we end up running with module randomization disabled.
> -        */
> -       module_alloc_base = (u64)_etext - MODULES_VSIZE;
> +bool __ro_after_init __kaslr_is_enabled = false;
>
> +void __init kaslr_init(void)
> +{
>         if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
>                 pr_info("KASLR disabled on command line\n");
> -               return 0;
> +               return;
>         }
>
> -       if (!kaslr_enabled()) {
> +       /*
> +        * The KASLR offset modulo MIN_KIMG_ALIGN is taken from the physical
> +        * placement of the image rather than from the seed, so a displacement
> +        * of less than MIN_KIMG_ALIGN means that no seed was provided.
> +        */
> +       if (kaslr_offset() < MIN_KIMG_ALIGN) {
>                 pr_warn("KASLR disabled due to lack of seed\n");
> -               return 0;
> +               return;
>         }
>
>         pr_info("KASLR enabled\n");
> +       __kaslr_is_enabled = true;
> +}
> +
> +int kaslr_module_init(void)
> +{
> +       u64 module_range;
> +       u32 seed;
> +
> +       /*
> +        * Set a reasonable default for module_alloc_base in case
> +        * we end up running with module randomization disabled.
> +        */
> +       module_alloc_base = (u64)_etext - MODULES_VSIZE;
>
>         seed = get_random_u32();
>
> @@ -80,4 +91,4 @@ static int __init kaslr_init(void)
>
>         return 0;
>  }
> -subsys_initcall(kaslr_init)
> +subsys_initcall(kaslr_module_init)
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index b8ec7b3ac9cb..417a8a86b2db 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -296,6 +296,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
>
>         *cmdline_p = boot_command_line;
>
> +       kaslr_init();
> +
>         /*
>          * If know now we are going to need KPTI then use non-global
>          * mappings from the start, avoiding the cost of rewriting
> --
> 2.30.2
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/6] arm64: module: improve module VA range selection

[Ard Biesheuvel]

On Fri, 12 May 2023 at 17:22, Mark Rutland <mark.rutland@arm.com> wrote:
>
> This series (based on v6.4-rc1) 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
>
> [1] https://lore.kernel.org/linux-arm-kernel/20230509111451.4184972-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
>

For the series,

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

(I spotted some typos in the commit log somewhere, please refer to my
other reply)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/6] arm64: module: improve module VA range selection

[Mark Rutland]

On Tue, May 30, 2023 at 12:31:54PM +0200, Ard Biesheuvel wrote:
> On Fri, 12 May 2023 at 17:22, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > This series (based on v6.4-rc1) aims to make arm64's module allocation
> > code more robust. [...]

> > 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
> 
> For the series,
> 
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

Thanks!

> (I spotted some typos in the commit log somewhere, please refer to my
> other reply)

Sorry about that; I spotted a few more when fixing that up, so I'll check the
entire series and post a v3 with all of that corrected.

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel