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

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

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
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

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,
special load and store instructions to use alternate keys?

quoted

I wouldn't call it POWER semantics. The way I implemented it on power
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
thing should work the same way on x86 and POWER.

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.  It should at least update the values loaded when a signal
is delivered and it should probably also update it for new threads.

For glibc, for example, I assume that you want signals to be delivered with
write access disabled to the GOT.  Otherwise you would fail to protect
against exploits that occur in signal context.  Glibc controls thread
creation, so the initial state on thread startup doesn't really matter, but
there will be more users than just glibc.

--Andy