kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Kees Cook <keescook@chromium.org>
Cc: Russell Currey <ruscur@russell.cc>,
	linuxppc-dev@lists.ozlabs.org, joel@jms.id.au,
	mpe@ellerman.id.au, ajd@linux.ibm.com, dja@axtens.net,
	npiggin@gmail.com, kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v5 0/5] Implement STRICT_MODULE_RWX for powerpc
Date: Wed, 30 Oct 2019 20:28:17 +0100	[thread overview]
Message-ID: <776c0722-eb8c-622a-a70b-f19ae07c1dc3@c-s.fr> (raw)
In-Reply-To: <201910301128.E7552CDD@keescook>



Le 30/10/2019 à 19:30, Kees Cook a écrit :
> On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:
>>
>>
>> Le 30/10/2019 à 08:31, Russell Currey a écrit :
>>> v4 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198268.html
>>> v3 cover letter: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-October/198023.html
>>>
>>> Changes since v4:
>>> 	[1/5]: Addressed review comments from Michael Ellerman (thanks!)
>>> 	[4/5]: make ARCH_HAS_STRICT_MODULE_RWX depend on
>>> 	       ARCH_HAS_STRICT_KERNEL_RWX to simplify things and avoid
>>> 	       STRICT_MODULE_RWX being *on by default* in cases where
>>> 	       STRICT_KERNEL_RWX is *unavailable*
>>> 	[5/5]: split skiroot_defconfig changes out into its own patch
>>>
>>> The whole Kconfig situation is really weird and confusing, I believe the
>>> correct resolution is to change arch/Kconfig but the consequences are so
>>> minor that I don't think it's worth it, especially given that I expect
>>> powerpc to have mandatory strict RWX Soon(tm).
>>
>> I'm not such strict RWX can be made mandatory due to the impact it has on
>> some subarches:
>> - On the 8xx, unless all areas are 8Mbytes aligned, there is a significant
>> overhead on TLB misses. And Aligning everthing to 8M is a waste of RAM which
>> is not acceptable on systems having very few RAM.
>> - On hash book3s32, we are able to map the kernel BATs. With a few alignment
>> constraints, we are able to provide STRICT_KERNEL_RWX. But we are unable to
>> provide exec protection on page granularity. Only on 256Mbytes segments. So
>> for modules, we have to have the vmspace X. It is also not possible to have
>> a kernel area RO. Only user areas can be made RO.
> 
> As I understand it, the idea was for it to be mandatory (or at least
> default-on) only for the subarches where it wasn't totally insane to
> accomplish. :) (I'm not familiar with all the details on the subarchs,
> but it sounded like the more modern systems would be the targets for
> this?)
> 

Yes I guess so.

I was just afraid by "I expect powerpc to have mandatory strict RWX"

By the way, we have an open issue #223 namely 'Make strict kernel RWX 
the default on 64-bit', so no worry as 32-bit is aside for now.

Christophe

  reply	other threads:[~2019-10-30 19:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30  7:31 [PATCH v5 0/5] Implement STRICT_MODULE_RWX for powerpc Russell Currey
2019-10-30  7:31 ` [PATCH v5 1/5] powerpc/mm: Implement set_memory() routines Russell Currey
2019-10-30  8:01   ` Christophe Leroy
2019-10-30  7:31 ` [PATCH v5 2/5] powerpc/kprobes: Mark newly allocated probes as RO Russell Currey
2019-11-01 14:23   ` Daniel Axtens
2019-11-02 10:45   ` Michael Ellerman
2019-12-05 23:47     ` Michael Ellerman
2019-12-12  6:43       ` Russell Currey
2019-10-30  7:31 ` [PATCH v5 3/5] powerpc/mm/ptdump: debugfs handler for W+X checks at runtime Russell Currey
2019-10-30  7:31 ` [PATCH v5 4/5] powerpc: Set ARCH_HAS_STRICT_MODULE_RWX Russell Currey
2019-10-30  7:31 ` [PATCH v5 5/5] powerpc/configs: Enable STRICT_MODULE_RWX in skiroot_defconfig Russell Currey
2019-10-31  0:05   ` Joel Stanley
2019-10-30  8:58 ` [PATCH v5 0/5] Implement STRICT_MODULE_RWX for powerpc Christophe Leroy
2019-10-30 18:30   ` Kees Cook
2019-10-30 19:28     ` Christophe Leroy [this message]
2019-10-31  0:09   ` Russell Currey

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=776c0722-eb8c-622a-a70b-f19ae07c1dc3@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=ajd@linux.ibm.com \
    --cc=dja@axtens.net \
    --cc=joel@jms.id.au \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --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).