From: Florian Weimer <fweimer@redhat.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-mm <linux-mm@kvack.org>,
Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: pkeys on POWER: Default AMR, UAMOR values
Date: Fri, 18 May 2018 23:09:20 +0200 [thread overview]
Message-ID: <59616677-49c3-c803-963d-c032168de529@redhat.com> (raw)
In-Reply-To: <20180518174448.GE5479@ram.oc3035372033.ibm.com>
On 05/18/2018 07:44 PM, Ram Pai wrote:
> Florian, is the behavior on x86 any different? A key allocated in the
> context off one thread is not meaningful in the context of any other
> thread.
>
> Since thread B was created prior to the creation of the key, and the key
> was created in the context of thread A, thread B neither inherits the
> key nor its permissions. Atleast that is how the semantics are supposed
> to work as per the man page.
>
> man 7 pkey
>
> " Applications using threads and protection keys should
> be especially careful. Threads inherit the protection key rights of the
> parent at the time of the clone(2), system call. Applications should
> either ensure that their own permissions are appropriate for child
> threads at the time when clone(2) is called, or ensure that each child
> thread can perform its own initialization of protection key rights."
I reported two separate issues (actually three, but the execve bug is in
a separate issue). The default, and the write restrictions.
The default is just a difference to x86 (however, x86 can be booted with
init_pkru=0 and behaves the same way, but we're probably going to remove
that).
The POWER implementation has the additional wrinkle that threads
launched early, before key allocation, can never change access rights
because they inherited not just the access rights, but also the access
rights access mask. This is different from x86, where all threads can
freely update access rights, and contradicts the behavior in the manpage
which says that a??each child thread can perform its own initialization of
protection key rightsa??. It can't do that if it is launched before key
allocation, which is not the right behavior IMO.
Thanks,
Florian
prev parent reply other threads:[~2018-05-18 21:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 13:17 pkeys on POWER: Default AMR, UAMOR values Florian Weimer
2018-05-18 14:35 ` Andy Lutomirski
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 [this message]
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=59616677-49c3-c803-963d-c032168de529@redhat.com \
--to=fweimer@redhat.com \
--cc=dave.hansen@intel.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=luto@amacapital.net \
/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;
as well as URLs for NNTP newsgroup(s).