All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Jordan Niethe <jniethe5@gmail.com>, linuxppc-dev@lists.ozlabs.org
Cc: ajd@linux.ibm.com, npiggin@gmail.com, cmr@codefail.de,
	aneesh.kumar@linux.ibm.com, naveen.n.rao@linux.ibm.com,
	dja@axtens.net
Subject: Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
Date: Thu, 29 Apr 2021 07:04:08 +0200	[thread overview]
Message-ID: <111c8736-fff9-ba0a-4749-f9388b32c9bf@csgroup.eu> (raw)
In-Reply-To: <20210429031602.2606654-4-jniethe5@gmail.com>



Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
> VMALLOC_END respectively. This reduces the need for special cases. For
> example, powerpc's module_alloc() was previously predicated on
> MODULES_VADDR being defined but now is unconditionally defined.
> 
> This will be useful reducing conditional code in other places that need
> to allocate from the module region (i.e., kprobes).
> 
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> v10: New to series
> v11: - Consider more places MODULES_VADDR was being used
> ---
>   arch/powerpc/include/asm/pgtable.h    | 11 +++++++++++
>   arch/powerpc/kernel/module.c          |  5 +----
>   arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
>   arch/powerpc/mm/ptdump/ptdump.c       |  4 ++--
>   4 files changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index c6a676714f04..882fda779648 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -39,6 +39,17 @@ struct mm_struct;
>   #define __S110	PAGE_SHARED_X
>   #define __S111	PAGE_SHARED_X
>   
> +#ifndef MODULES_VADDR
> +#define MODULES_VADDR VMALLOC_START
> +#define MODULES_END VMALLOC_END
> +#endif
> +
> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)

No no.

TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.

Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?

> +#if TASK_SIZE > MODULES_VADDR
> +#error TASK_SIZE > MODULES_VADDR
> +#endif
> +#endif
> +
>   #ifndef __ASSEMBLY__
>   
>   /* Keep these as a macros to avoid include dependency mess */
> diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> index fab84024650c..c60c7457ff47 100644
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@ -15,6 +15,7 @@
>   #include <linux/sort.h>
>   #include <asm/setup.h>
>   #include <asm/sections.h>
> +#include <linux/mm.h>
>   
>   static LIST_HEAD(module_bug_list);
>   
> @@ -88,7 +89,6 @@ int module_finalize(const Elf_Ehdr *hdr,
>   	return 0;
>   }
>   
> -#ifdef MODULES_VADDR
>   static __always_inline void *
>   __module_alloc(unsigned long size, unsigned long start, unsigned long end)
>   {
> @@ -102,8 +102,6 @@ void *module_alloc(unsigned long size)
>   	unsigned long limit = (unsigned long)_etext - SZ_32M;
>   	void *ptr = NULL;
>   
> -	BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> -
>   	/* First try within 32M limit from _etext to avoid branch trampolines */
>   	if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
>   		ptr = __module_alloc(size, limit, MODULES_END);
> @@ -113,4 +111,3 @@ void *module_alloc(unsigned long size)
>   
>   	return ptr;
>   }
> -#endif
> diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
> index cf8770b1a692..42c057366ac7 100644
> --- a/arch/powerpc/mm/kasan/kasan_init_32.c
> +++ b/arch/powerpc/mm/kasan/kasan_init_32.c
> @@ -116,11 +116,11 @@ static void __init kasan_unmap_early_shadow_vmalloc(void)
>   
>   	kasan_update_early_region(k_start, k_end, __pte(0));
>   
> -#ifdef MODULES_VADDR
> -	k_start = (unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR);
> -	k_end = (unsigned long)kasan_mem_to_shadow((void *)MODULES_END);
> -	kasan_update_early_region(k_start, k_end, __pte(0));
> -#endif
> +	if (MODULES_VADDR != VMALLOC_START && MODULES_END != VMALLOC_END) {

Shouldn't it be an || ?

As soon as either MODULES_VADDR or MODULES_END differs from the vmalloc boundaries, it needs to be 
done I think.

> +		k_start = (unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR);
> +		k_end = (unsigned long)kasan_mem_to_shadow((void *)MODULES_END);
> +		kasan_update_early_region(k_start, k_end, __pte(0));
> +	}
>   }
>   
>   void __init kasan_mmu_init(void)
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index aca354fb670b..0431457f668f 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -73,7 +73,7 @@ struct addr_marker {
>   
>   static struct addr_marker address_markers[] = {
>   	{ 0,	"Start of kernel VM" },
> -#ifdef MODULES_VADDR
> +#if defined(CONFIG_BOOK32_32) && defined(CONFIG_STRICT_KERNEL_RWX)

Not valid anymore, see https://github.com/linuxppc/linux/commit/80edc68e0479 and 
https://github.com/linuxppc/linux/commit/9132a2e82adc

The best would be to be able to do something like:

#if MODULES_VADDR != VMALLOC_START

If it doesn't work, then it has to be

#if defined(CONFIG_BOOK32_32) || defined(CONFIG_PPC_8xx)

>   	{ 0,	"modules start" },
>   	{ 0,	"modules end" },
>   #endif
> @@ -359,7 +359,7 @@ static void populate_markers(void)
>   #else
>   	address_markers[i++].start_address = TASK_SIZE;
>   #endif
> -#ifdef MODULES_VADDR
> +#if defined(CONFIG_BOOK32_32) && defined(CONFIG_STRICT_KERNEL_RWX)

Same.

>   	address_markers[i++].start_address = MODULES_VADDR;
>   	address_markers[i++].start_address = MODULES_END;
>   #endif
> 

  reply	other threads:[~2021-04-29  5:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-29  3:15 [PATCH v11 0/9] powerpc: Further Strict RWX support Jordan Niethe
2021-04-29  3:15 ` [PATCH v11 1/9] powerpc/mm: Implement set_memory() routines Jordan Niethe
2021-04-29  7:32   ` Christophe Leroy
2021-05-03  5:02     ` Jordan Niethe
2021-04-29  3:15 ` [PATCH v11 2/9] powerpc/lib/code-patching: Set up Strict RWX patching earlier Jordan Niethe
2021-04-29  4:53   ` Christophe Leroy
2021-05-05  5:22     ` Jordan Niethe
2021-04-29  3:15 ` [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END} Jordan Niethe
2021-04-29  5:04   ` Christophe Leroy [this message]
2021-05-03  5:39     ` Jordan Niethe
2021-05-03  5:57       ` Christophe Leroy
2021-05-03  6:16         ` Jordan Niethe
2021-05-03  6:22           ` Christophe Leroy
2021-05-03  6:26             ` Jordan Niethe
2021-05-03  6:32               ` Christophe Leroy
2021-04-29  3:15 ` [PATCH v11 4/9] powerpc/kprobes: Mark newly allocated probes as ROX Jordan Niethe
2021-04-29  3:15 ` [PATCH v11 5/9] powerpc/bpf: Remove bpf_jit_free() Jordan Niethe
2021-04-29  3:15 ` [PATCH v11 6/9] powerpc/bpf: Write protect JIT code Jordan Niethe
2021-04-29  3:16 ` [PATCH v11 7/9] powerpc: Set ARCH_HAS_STRICT_MODULE_RWX Jordan Niethe
2021-04-29  3:16 ` [PATCH v11 8/9] powerpc/mm: implement set_memory_attr() Jordan Niethe
2021-04-29  3:16 ` [PATCH v11 9/9] powerpc/32: use set_memory_attr() Jordan Niethe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=111c8736-fff9-ba0a-4749-f9388b32c9bf@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=ajd@linux.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=cmr@codefail.de \
    --cc=dja@axtens.net \
    --cc=jniethe5@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.