On Thu, 2019-02-07 at 14:37 -0200, Thiago Jung Bauermann wrote:
> Russell Currey <rus...@russell.cc> writes:
> > On Thu, 2019-02-07 at 15:08 +1000, Nicholas Piggin wrote:
> > > Russell Currey's on February 6, 2019 4:28 pm:
> > > >
> > > > Fixes: 3b10d0095a1e ("powerpc/mm/radix: Prevent kernel
> > > > execution of
> > > > user
> > > > space")
> > > > Cc: <sta...@vger.kernel.org>
> > > > Signed-off-by: Russell Currey <rus...@russell.cc>
> > >
> > > Good catch and debugging. This really should be a quirk, we don't
> > > want
> > > to have to restore this thing on a thread switch.
> > >
> > > Can we put it under a CONFIG option if we're not using IAMR?
> >
> > I don't exactly know when we do or don't use the IAMR (since the
> > only
> > thing I've used it for is radix). When wouldn't we care about
> > restoring it on hash?
>
> On hash it's used for memory protection keys (code is in
> arch/powerpc/mm/pkeys.c). The kernel doesn't use protection keys, but
> userspace apps may use it explicitly via specific syscalls
> (pkey_alloc(), pkey_mprotect, pkey_free()).
>
> Also, the kernel may use a protection key if the process does an
> mmap(PROT_EXEC).
I don't understand how this would work, though - in this case we
wouldn't know on boot if we were going to use the IAMR or not. On
radix (unless booting with nosmep) it would always be used, but on hash
it seems it depends on what userspace does. How exactly would a
runtime toggle of "IAMR in use" work?
With a CONFIG option it would have to depend on PPC_MEM_KEYS ||
PPC_RADIX_MMU, but those are (pretty much) always going to be on in P8
and P9, which I already check for.
>
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
>
