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
next prev parent 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).