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

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

On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote:

quoted

On 05/08/2018 04:49 AM, Andy Lutomirski wrote:

quoted

On Mon, May 7, 2018 at 2:48 AM Florian Weimer [off-list ref]

wrote:

quoted

quoted

quoted

On 05/03/2018 06:05 AM, Andy Lutomirski wrote:

quoted

On Wed, May 2, 2018 at 7:11 PM Ram Pai [off-list ref] wrote:

quoted

On Wed, May 02, 2018 at 09:23:49PM +0000, Andy Lutomirski wrote:

quoted

quoted

If I recall correctly, the POWER maintainer did express a strong

desire

quoted

quoted

quoted

back then for (what is, I believe) their current semantics, which

my

quoted

quoted

quoted

quoted

quoted

quoted

quoted

PKEY_ALLOC_SIGNALINHERIT patch implements for x86, too.

Ram, I really really don't like the POWER semantics.  Can you give

some

quoted

quoted

quoted

quoted

justification for them?  Does POWER at least have an atomic way for
userspace to modify just the key it wants to modify or, even

better,

quoted

quoted

quoted

quoted

quoted

quoted

special load and store instructions to use alternate keys?

quoted

I wouldn't call it POWER semantics. The way I implemented it on

power

quoted

quoted

quoted

quoted

quoted

lead to the semantics, given that nothing was explicitly stated
about how the semantics should work within a signal handler.

I think that this is further evidence that we should introduce a new
pkey_alloc() mode and deprecate the old.  To the extent possible,

this

quoted

quoted

quoted

quoted

thing should work the same way on x86 and POWER.

quoted

Do you propose to change POWER or to change x86?

Sorry for being slow to reply.  I propose to introduce a new
PKEY_ALLOC_something variant on x86 and POWER and to make the behavior
match on both.

So basically implement PKEY_ALLOC_SETSIGNAL for POWER, and keep the
existing (different) behavior without the flag?

Ram, would you be okay with that?  Could you give me a hand if
necessary?  (I assume we have silicon in-house because it's a
long-standing feature of the POWER platform which was simply dormant
on Linux until now.)

Yes. I can help you with that.

So let me see if I understand the overall idea.

Application can allocate new keys through a new syscall
sys_pkey_alloc_1(flags, init_val, sig_init_val)

'sig_init_val' is the permission-state of the key in signal context.

The kernel will set the permission of each keys to their
corresponding values when entering the signal handler and revert
on return from the signal handler.

just like init_val, sig_init_val also percolates to children threads.

I was imagining it would be just pkey_alloc(SOME_NEW_FLAG, init_val); and
the init val would be used for the current thread and for signal handlers.
New threads would inherit their parents' values.  The latter is certainly
up for negotiation, but it's the simplest behavior, and it's not obvious to
be that it's wrong.

--Andy