[PATCH] powerpc/powernv/idle: Restore IAMR after idle

[Nicholas Piggin]

Michael Ellerman's on February 8, 2019 11:04 am:
> Nicholas Piggin <npiggin at 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: <stable at vger.kernel.org>
>>> Signed-off-by: Russell Currey <ruscur at 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.

>> Can we put it under a CONFIG option if we're not using IAMR?
> 
> We'll always be using it with Radix, and we might be using it for pkeys
> on hash, unless pkeys are compiled out. But I don't really expect anyone
> to be running with pkeys compiled out.
> 
> So I think the only case we could optimise is that we're on hash and the
> current thread has an IAMR of 0, then we could just not restore
> (assuming we come out of idle with IAMR=0).
> 
> But maybe I'm not understanding.

Nah it sounds like more trouble than it's worth in that case.

Thanks,
Nick