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

On Wed, May 02, 2018 at 09:18:11PM +0000, Andy Lutomirski wrote:

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

quoted

quoted

Ram, would you please comment?

quoted

on POWER the pkey behavior will remain the same at entry or at exit from
the signal handler.  For eg:  if a key is read-disabled on entry into
the signal handler, and gets read-enabled in the signal handler, than it
will continue to be read-enabled on return from the signal handler.

quoted

In other words, changes to key permissions persist across signal
boundaries.

I don't know about POWER's ISA, but this is crappy behavior.  If a thread
temporarily grants itself access to a restrictive memory key and then gets
a signal, the signal handler should *not* have access to that key.

This is a new requirement that I was not aware off. Its not documented
anywhere AFAICT.  Regardless of how the ISA behaves, its still a kernel
behavior that needs to be clearly defined.

-- 
Ram Pai

On 05/03/2018 01:38 AM, Ram Pai wrote:

This is a new requirement that I was not aware off. Its not documented
anywhere AFAICT.

Correct.  All inheritance behavior was deliberately left unspecified.

I'm surprised about the reluctance to fix the x86 behavior.  Are there 
any applications at all for the current semantics?

I guess I can implement this particular glibc hardening on POWER only 
for now.

Thanks,
Florian