| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPhsuW7xE8sz8Nh2AdNb62k=8kgEPxaBCw3w50EfXraxmKca-A@mail.gmail.com>
Date: Fri, 16 Jun 2023 11:53:54 -0700
From: Song Liu <song@...nel.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
"David S. Miller" <davem@...emloft.net>,
Dinh Nguyen <dinguyen@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>,
Helge Deller <deller@....de>,
Huacai Chen <chenhuacai@...nel.org>,
Kent Overstreet <kent.overstreet@...ux.dev>,
Luis Chamberlain <mcgrof@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Nadav Amit <nadav.amit@...il.com>,
"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
Palmer Dabbelt <palmer@...belt.com>,
Puranjay Mohan <puranjay12@...il.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
Russell King <linux@...linux.org.uk>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>, bpf@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
linux-mm@...ck.org, linux-modules@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev,
netdev@...r.kernel.org, sparclinux@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2 04/12] mm/execmem, arch: convert remaining overrides of
module_alloc to execmem
On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport <rppt@...nel.org> wrote:
[...]
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 5af4975caeb5..c3d999f3a3dd 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -17,56 +17,50 @@
> #include <linux/moduleloader.h>
> #include <linux/scs.h>
> #include <linux/vmalloc.h>
> +#include <linux/execmem.h>
> #include <asm/alternative.h>
> #include <asm/insn.h>
> #include <asm/scs.h>
> #include <asm/sections.h>
>
> -void *module_alloc(unsigned long size)
> +static struct execmem_params execmem_params = {
> + .modules = {
> + .flags = EXECMEM_KASAN_SHADOW,
> + .text = {
> + .alignment = MODULE_ALIGN,
> + },
> + },
> +};
> +
> +struct execmem_params __init *execmem_arch_params(void)
> {
> u64 module_alloc_end = module_alloc_base + MODULES_VSIZE;
> - gfp_t gfp_mask = GFP_KERNEL;
> - void *p;
> -
> - /* Silence the initial allocation */
> - if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
> - gfp_mask |= __GFP_NOWARN;
>
> - if (IS_ENABLED(CONFIG_KASAN_GENERIC) ||
> - IS_ENABLED(CONFIG_KASAN_SW_TAGS))
> - /* don't exceed the static module region - see below */
> - module_alloc_end = MODULES_END;
> + execmem_params.modules.text.pgprot = PAGE_KERNEL;
> + execmem_params.modules.text.start = module_alloc_base;
I think I mentioned this earlier. For arm64 with CONFIG_RANDOMIZE_BASE,
module_alloc_base is not yet set when execmem_arch_params() is
called. So we will need some extra logic for this.
Thanks,
Song
> + execmem_params.modules.text.end = module_alloc_end;
>
> - p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> - module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> - NUMA_NO_NODE, __builtin_return_address(0));
> -
> - if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> + /*
> + * KASAN without KASAN_VMALLOC can only deal with module
> + * allocations being served from the reserved module region,
> + * since the remainder of the vmalloc region is already
> + * backed by zero shadow pages, and punching holes into it
> + * is non-trivial. Since the module region is not randomized
> + * when KASAN is enabled without KASAN_VMALLOC, it is even
> + * less likely that the module region gets exhausted, so we
> + * can simply omit this fallback in that case.
> + */
> + if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> (IS_ENABLED(CONFIG_KASAN_VMALLOC) ||
> (!IS_ENABLED(CONFIG_KASAN_GENERIC) &&
> - !IS_ENABLED(CONFIG_KASAN_SW_TAGS))))
> - /*
> - * KASAN without KASAN_VMALLOC can only deal with module
> - * allocations being served from the reserved module region,
> - * since the remainder of the vmalloc region is already
> - * backed by zero shadow pages, and punching holes into it
> - * is non-trivial. Since the module region is not randomized
> - * when KASAN is enabled without KASAN_VMALLOC, it is even
> - * less likely that the module region gets exhausted, so we
> - * can simply omit this fallback in that case.
> - */
> - p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> - module_alloc_base + SZ_2G, GFP_KERNEL,
> - PAGE_KERNEL, 0, NUMA_NO_NODE,
> - __builtin_return_address(0));
> -
> - if (p && (kasan_alloc_module_shadow(p, size, gfp_mask) < 0)) {
> - vfree(p);
> - return NULL;
> + !IS_ENABLED(CONFIG_KASAN_SW_TAGS)))) {
> + unsigned long end = module_alloc_base + SZ_2G;
> +
> + execmem_params.modules.text.fallback_start = module_alloc_base;
> + execmem_params.modules.text.fallback_end = end;
> }
>
> - /* Memory is intended to be executable, reset the pointer tag. */
> - return kasan_reset_tag(p);
> + return &execmem_params;
> }
>
> enum aarch64_reloc_op {
Powered by blists - more mailing lists