Re: [PATCH v5 0/5] Implement STRICT_MODULE_RWX for powerpc

On Wed, Oct 30, 2019 at 09:58:19AM +0100, Christophe Leroy wrote:

Le 30/10/2019 à 08:31, Russell Currey a écrit :

quoted

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?)

-- 
Kees Cook