[PATCH v5 0/5] Implement STRICT_MODULE_RWX for powerpc
Kees Cook
keescook at chromium.org
Thu Oct 31 05:30:13 AEDT 2019
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
More information about the Linuxppc-dev
mailing list