linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Russell Currey <ruscur@russell.cc>, linuxppc-dev@lists.ozlabs.org
Cc: ajd@linux.ibm.com, kernel-hardening@lists.openwall.com,
	npiggin@gmail.com, joel@jms.id.au,
	Jordan Niethe <jniethe5@gmail.com>,
	dja@axtens.net
Subject: Re: [PATCH v4 8/8] powerpc/mm: Disable set_memory() routines when strict RWX isn't enabled
Date: Wed, 26 Feb 2020 08:19:19 +0100	[thread overview]
Message-ID: <2a9988ec-c115-8fe8-4c68-82eb2fa43d6b@c-s.fr> (raw)
In-Reply-To: <20200226062403.63790-9-ruscur@russell.cc>



Le 26/02/2020 à 07:24, Russell Currey a écrit :
> There are a couple of reasons that the set_memory() functions are
> problematic when STRICT_KERNEL_RWX isn't enabled:
> 
>   - The linear mapping is a different size and apply_to_page_range()
> 	may modify a giant section, breaking everything

I don't understand.

>   - patch_instruction() doesn't know to work around a page being marked
>   	RO, and will subsequently crash

Is patch_instruction() involved at all ?

> 
> The latter can be replicated by building a kernel with the set_memory()
> patches but with STRICT_KERNEL_RWX off and running ftracetest.
> 
> Reported-by: Jordan Niethe <jniethe5@gmail.com>
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> ---
> v4: new
> 
>   arch/powerpc/mm/pageattr.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
> index ee6b5e3b7604..ff111930cf5e 100644
> --- a/arch/powerpc/mm/pageattr.c
> +++ b/arch/powerpc/mm/pageattr.c
> @@ -96,12 +96,17 @@ static int set_page_attr(pte_t *ptep, unsigned long addr, void *data)
>   
>   int set_memory_attr(unsigned long addr, int numpages, pgprot_t prot)

Isn't it change_memory_attr() that is a problem for you ?

>   {
> -	unsigned long start = ALIGN_DOWN(addr, PAGE_SIZE);
> -	unsigned long sz = numpages * PAGE_SIZE;
> +	unsigned long start, size;
> +
> +	if (!IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
> +		return 0;


Doing this you break patch 7:
mark_initmem_nx() is called regardless of CONFIG_STRICT_KERNEL_RWX
__kernel_map_pages() depends on CONFIG_DEBUG_PAGEALLOC which doesn't 
depend on CONFIG_STRICT_KERNEL_RWX


>   
>   	if (!numpages)
>   		return 0;
>   
> -	return apply_to_page_range(&init_mm, start, sz, set_page_attr,
> +	start = ALIGN_DOWN(addr, PAGE_SIZE);
> +	size = numpages * PAGE_SIZE;
> +
> +	return apply_to_page_range(&init_mm, start, size, set_page_attr,

You don't need to move start and size calculation and change the above.

>   				   (void *)pgprot_val(prot));
>   }
> 

Christophe

      reply	other threads:[~2020-02-26  7:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26  6:23 [PATCH v4 0/8] set_memory() routines and STRICT_MODULE_RWX Russell Currey
2020-02-26  6:23 ` [PATCH v4 1/8] powerpc/mm: Implement set_memory() routines Russell Currey
2020-02-26  6:23 ` [PATCH v4 2/8] powerpc/kprobes: Mark newly allocated probes as RO Russell Currey
2020-02-26  6:23 ` [PATCH v4 3/8] powerpc/mm/ptdump: debugfs handler for W+X checks at runtime Russell Currey
2020-02-26  6:23 ` [PATCH v4 4/8] powerpc: Set ARCH_HAS_STRICT_MODULE_RWX Russell Currey
2020-02-26  6:24 ` [PATCH v4 5/8] powerpc/configs: Enable STRICT_MODULE_RWX in skiroot_defconfig Russell Currey
2020-02-26  6:24 ` [PATCH v4 6/8] powerpc/mm: implement set_memory_attr() Russell Currey
2020-02-26  6:24 ` [PATCH v4 7/8] powerpc/32: use set_memory_attr() Russell Currey
2020-02-26  6:24 ` [PATCH v4 8/8] powerpc/mm: Disable set_memory() routines when strict RWX isn't enabled Russell Currey
2020-02-26  7:19   ` Christophe Leroy [this message]

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=2a9988ec-c115-8fe8-4c68-82eb2fa43d6b@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=ajd@linux.ibm.com \
    --cc=dja@axtens.net \
    --cc=jniethe5@gmail.com \
    --cc=joel@jms.id.au \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=ruscur@russell.cc \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).