On Mon, May 14, 2018 at 02:01:23PM +0200, Florian Weimer wrote: > On 05/09/2018 04:41 PM, Andy Lutomirski wrote: > >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 > >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. > > >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 > >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 > >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. RP -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
