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