Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On Wed, May 16, 2018 at 1:52 PM Ram Pai [off-list ref] wrote:

On Mon, May 14, 2018 at 02:01:23PM +0200, Florian Weimer wrote:

quoted

On 05/09/2018 04:41 PM, Andy Lutomirski wrote:

quoted

Hmm.  I can get on board with the idea that fork() / clone() /
pthread_create() are all just special cases of the idea that the thread
that*calls*  them should have the right pkey values, and the latter is
already busted given our inability to asynchronously propagate the new

mode

quoted

quoted

in pkey_alloc().  So let's so PKEY_ALLOC_SETSIGNAL as a starting point.

Ram, any suggestions for implementing this on POWER?

I suspect the changes will go in
restore_user_regs() and save_user_regs().  These are the functions
that save and restore register state before entry and exit into/from
a signal handler.

quoted

quoted

One thing we could do, though: the current initual state on process
creation is all access blocked on all keys.  We could change it so that
half the keys are fully blocked and half are read-only.  Then we could

add

quoted

quoted

a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
initial state*and*  does the setsignal thing.  If there are no keys

left

quoted

quoted

with the correct initial state, then it fails.

The initial PKRU value can currently be configured by the system
administrator.  I fear this approach has too many moving parts to be
viable.

Sounds like on x86  keys can go active in signal-handler
without any explicit allocation request by the application.  This is not
the case on power. Is that API requirement? Hope not.

On x86, signals are currently delivered with all keys locked all the way
down (except for the magic one we use to emulate no-read access).  I would
hesitate to change this for existing applications.