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
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 whe
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 Florian Weimer
> wrot
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 cases of the idea that
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 pk
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 AM, Andy Lutomirski wrote:
> > >>>On Wed,
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 wrote:
> >>>
> On Wed, Ma
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 administrat
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 and half are read-on
> 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 could add
>> a PKEY_ALLOC
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 asynch
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 Pai wrote:
> >>>
> On Wed, May 02,
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 Lutomirski wrote:
If I recall correctly, the PO
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 correctly, the POWER maintainer did express a
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 f
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 key is read-disabled on
16 matches
Mail list logo
