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

On 05/16/2018 10:35 PM, Ram Pai wrote: 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. I would keep the existing system

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

On 05/16/2018 11:07 PM, Ram Pai wrote: what would change the key-permission-values enforced in signal-handler context? Or can it never be changed, ones set through sys_pkey_alloc()? The access rights can only be set by pkey_alloc and are unchanged after that (so we do not have to discuss

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

On Wed, May 16, 2018 at 01:37:46PM -0700, Andy Lutomirski wrote: > On Wed, May 16, 2018 at 1:35 PM Ram Pai wrote: > > > On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote: > > > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > > >On Mon, May 7, 2018 at 2:48 AM

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

On Wed, May 16, 2018 at 1:52 PM Ram Pai wrote: > 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

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

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

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

On Wed, May 16, 2018 at 1:35 PM Ram Pai wrote: > On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote: > > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > >On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > > > >>On 05/03/2018 06:05

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

On Tue, May 08, 2018 at 02:40:46PM +0200, Florian Weimer wrote: > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > >On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > >>On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > >>>On Wed, May 2, 2018 at 7:11 PM Ram Pai

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

On 05/14/2018 08:34 AM, Florian Weimer wrote: >>> The initial PKRU value can currently be configured by the system >>> administrator.  I fear this approach has too many moving parts to be >>> viable. >> >> Honestly, I think we should drop that option. I don’t see how we can >> expect an

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

On 05/14/2018 05:32 PM, Andy Lutomirski wrote: On May 14, 2018, at 5:01 AM, Florian Weimer wrote: 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

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

> On May 14, 2018, at 5:01 AM, Florian Weimer wrote: > >> 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

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

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

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

On Tue, May 8, 2018 at 5:40 AM Florian Weimer wrote: > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > >> On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > >>> On Wed, May 2, 2018 at 7:11 PM Ram

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

On 05/08/2018 04:49 AM, Andy Lutomirski wrote: On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: On 05/03/2018 06:05 AM, Andy Lutomirski wrote: On Wed, May 2, 2018 at 7:11 PM Ram Pai wrote: On Wed, May 02, 2018 at 09:23:49PM +, Andy

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

On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > > On Wed, May 2, 2018 at 7:11 PM Ram Pai wrote: > > > >> On Wed, May 02, 2018 at 09:23:49PM +, Andy Lutomirski wrote: > >>> > If I recall

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

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

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

On Wed, May 02, 2018 at 09:18:11PM +, Andy Lutomirski wrote: > On Wed, May 2, 2018 at 2:13 PM Ram Pai wrote: > > > > > Ram, would you please comment? > > > on POWER the pkey behavior will remain the same at entry or at exit from > > the signal handler. For eg: if a