linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Florian Weimer <fweimer@redhat.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux-MM <linux-mm@kvack.org>,
	linuxram@us.ibm.com, Dave Hansen <dave.hansen@intel.com>
Subject: Re: pkeys on POWER: Default AMR, UAMOR values
Date: Fri, 18 May 2018 07:35:01 -0700	[thread overview]
Message-ID: <CALCETrXx_gUVQEvWjFNOBHqzVM+VSaMaRAX=11e7L=8BLHEagw@mail.gmail.com> (raw)
In-Reply-To: <36b98132-d87f-9f75-f1a9-feee36ec8ee6@redhat.com>

On Fri, May 18, 2018 at 6:17 AM Florian Weimer <fweimer@redhat.com> wrote:

> I'm working on adding POWER pkeys support to glibc.  The coding work is
> done, but I'm faced with some test suite failures.

> Unlike the default x86 configuration, on POWER, existing threads have
> full access to newly allocated keys.

> Or, more precisely, in this scenario:

> * Thread A launches thread B
> * Thread B waits
> * Thread A allocations a protection key with pkey_alloc
> * Thread A applies the key to a page
> * Thread A signals thread B
> * Thread B starts to run and accesses the page

> Then at the end, the access will be granted.

> I hope it's not too late to change this to denied access.

> Furthermore, I think the UAMOR value is wrong as well because it
> prevents thread B at the end to set the AMR register.  In particular, if
> I do this

> * … (as before)
> * Thread A signals thread B
> * Thread B sets the access rights for the key to PKEY_DISABLE_ACCESS
> * Thread B reads the current access rights for the key

> then it still gets 0 (all access permitted) because the original UAMOR
> value inherited from thread A prior to the key allocation masks out the
> access right update for the newly allocated key.

This type of issue is why I think that a good protection key ISA would not
have a usermode read-the-whole-register or write-the-whole-register
operation at all.  It's still not clear to me that there is any good
kernel-mode solution.  But at least x86 defaults to deny-everything, which
is more annoying but considerably safer than POWER's behavior.

--Andy

  reply	other threads:[~2018-05-18 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 13:17 Florian Weimer
2018-05-18 14:35 ` Andy Lutomirski [this message]
2018-05-18 17:44 ` Ram Pai
2018-05-18 19:39   ` Andy Lutomirski
2018-05-18 21:13     ` Florian Weimer
2018-05-19  0:52       ` Ram Pai
2018-05-19  5:15         ` Florian Weimer
2018-05-18 21:09   ` Florian Weimer

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CALCETrXx_gUVQEvWjFNOBHqzVM+VSaMaRAX=11e7L=8BLHEagw@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=dave.hansen@intel.com \
    --cc=fweimer@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox