LinuxPPC-Dev Archive on
 help / color / Atom feed
From: Nicholas Piggin <>
	Michael Ellerman <>,
	Russell Currey <>
Subject: Re: [PATCH] powerpc/powernv/idle: Restore IAMR after idle
Date: Tue, 19 Feb 2019 14:21:04 +1000
Message-ID: <1550549702.xfczazszdw.astroid@bobo.none> (raw)
In-Reply-To: <>

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


  reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06  6:28 Russell Currey
2019-02-07  4:29 ` Michael Ellerman
2019-02-07  6:28   ` Russell Currey
2019-02-07  5:08 ` Nicholas Piggin
2019-02-07  6:33   ` Russell Currey
2019-02-07 16:37     ` Thiago Jung Bauermann
2019-02-07 22:38       ` Russell Currey
2019-02-08  1:04   ` Michael Ellerman
2019-02-19  4:21     ` Nicholas Piggin [this message]
2019-02-20  6:04       ` Akshay Adiga
2019-02-20 11:18         ` Russell Currey
2019-02-20  7:15 ` Akshay Adiga
2019-02-20 11:25   ` Russell Currey
2019-02-20  8:58 ` Akshay Adiga
2019-02-20 11:20   ` Russell Currey

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1550549702.xfczazszdw.astroid@bobo.none \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LinuxPPC-Dev Archive on

Archives are clonable:
	git clone --mirror linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ \
	public-inbox-index linuxppc-dev

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox