On Wed, 2019-02-20 at 11:34 +0530, Akshay Adiga wrote:
> On Tue, Feb 19, 2019 at 02:21:04PM +1000, Nicholas Piggin wrote:
> > Michael Ellerman's on February 8, 2019 11:04 am:
> > > Nicholas Piggin <npig...@gmail.com> writes:
> > > > Russell Currey's on February 6, 2019 4:28 pm:
> > > > > Without restoring the IAMR after idle, execution prevention
> > > > > on POWER9
> > > > > with Radix MMU is overwritten and the kernel can freely
> > > > > execute userspace without
> > > > > faulting.
> > > > >
> > > > > This is necessary when returning from any stop state that
> > > > > modifies user
> > > > > state, as well as hypervisor state.
> > > > >
> > > > > To test how this fails without this patch, load the lkdtm
> > > > > driver and
> > > > > do the following:
> > > > >
> > > > > echo EXEC_USERSPACE > /sys/kernel/debug/provoke-
> > > > > crash/DIRECT
> > > > >
> > > > > which won't fault, then boot the kernel with powersave=off,
> > > > > where it
> > > > > will fault. Applying this patch will fix this.
> > > > >
> > > > > 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.
> > >
> > > I'm not sure I follow. We don't context switch it on Radix, but
> > > we do
> > > on hash if pkeys are enabled.
> >
> > Badly worded, I mean a hardware quirk. It should follow thread
> > switches. Still, avoiding it for the no-loss case is better than
> > nothing. We can just revisit it as an optimization if future
> > hardware does not require the restore.
>
> Apparently, the POWER9 Processor User’s Manual v2.0 documents that
> IAMR can be lost, and that is not just the end.
>
> Pasting excerpt from "Section 23.5.9.2 State Loss and
> Restoration,Page 309"
>
> On the POWER9 core, the only state that can be lost for
> Stop levels less than four, when PSSCR[ESL] = ‘1’ are the
> following SPRs: CR, FPSCR, VSCR, XER, DSCR, AMR, IAMR, UAMOR,
> AMOR, DAWR, DAWRX.
>
> My observation is that AMOR is being used in kernel as of today
> and AMOR is also lost (recreated in similar scenarios where
> IAMR is lost).
>
I can add AMOR to this patch (or you can send a patch, either way).
