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
