Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Wed, Jul 12, 2017 at 08:08:56AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > > Currently sys_pkey_create() provides the ability to disable read
> > > > > and write permission on the key, at  creation. powerpc  has  the
> > > > > hardware support to disable execute on a pkey as well.This patch
> > > > > enhances the interface to let disable execute  at  key  creation
> > > > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > > > specified.
> > > 
> > > That leads to the question... How do you tell userspace.
> > > 
> > > (apologies if I missed that in an existing patch in the series)
> > > 
> > > How do we inform userspace of the key capabilities ? There are at least
> > > two things userspace may want to know already:
> > > 
> > >  - What protection bits are supported for a key
> > 
> > the userspace is the one which allocates the keys and enables/disables the
> > protection bits on the key. the kernel is just a facilitator. Now if the
> > use space wants to know the current permissions on a given key, it can
> > just read the AMR/PKRU register on powerpc/intel respectively.
> 
> You misunderstand. How does userspace knows on a given system whether
> execute permission control is supported for keys ?

Ah..sorry. did not catch that part.

Yes the current patch set does not make that information available. The
indirect way of find this out is, to try to allocate a key with
execute-disable permission and decide based on the pass/fail status.

we can expose that information through a procfs/sysfs interface.

RP

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Wed, Jul 12, 2017 at 08:08:56AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > > Currently sys_pkey_create() provides the ability to disable read
> > > > > and write permission on the key, at  creation. powerpc  has  the
> > > > > hardware support to disable execute on a pkey as well.This patch
> > > > > enhances the interface to let disable execute  at  key  creation
> > > > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > > > specified.
> > > 
> > > That leads to the question... How do you tell userspace.
> > > 
> > > (apologies if I missed that in an existing patch in the series)
> > > 
> > > How do we inform userspace of the key capabilities ? There are at least
> > > two things userspace may want to know already:
> > > 
> > >  - What protection bits are supported for a key
> > 
> > the userspace is the one which allocates the keys and enables/disables the
> > protection bits on the key. the kernel is just a facilitator. Now if the
> > use space wants to know the current permissions on a given key, it can
> > just read the AMR/PKRU register on powerpc/intel respectively.
> 
> You misunderstand. How does userspace knows on a given system whether
> execute permission control is supported for keys ?

Ah..sorry. did not catch that part.

Yes the current patch set does not make that information available. The
indirect way of find this out is, to try to allocate a key with
execute-disable permission and decide based on the pass/fail status.

we can expose that information through a procfs/sysfs interface.

RP

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/11/2017 03:14 PM, Ram Pai wrote:
> Now how many does the kernel use to reserve for itself is something
> the kernel knows too and hence can expose it, though the information
> may change dynamically as the kernel reserves and releases the key
> based on its internal needs. 
> 
> So i think we can expose this informaton through procfs/sysfs and let
> the application decide how it wants to use the information.

Why bother?  On x86, you'll be told either 14 or 15 depending on whether
you tried to create a mapping in the process without execute permission.
 You can't use all 14 or 15 unless you actually call pkey_alloc() anyway
because the /proc check is inherently racy.

I'm just not sure I see the value in creating a new ABI for it.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/11/2017 03:14 PM, Ram Pai wrote:
> Now how many does the kernel use to reserve for itself is something
> the kernel knows too and hence can expose it, though the information
> may change dynamically as the kernel reserves and releases the key
> based on its internal needs. 
> 
> So i think we can expose this informaton through procfs/sysfs and let
> the application decide how it wants to use the information.

Why bother?  On x86, you'll be told either 14 or 15 depending on whether
you tried to create a mapping in the process without execute permission.
 You can't use all 14 or 15 unless you actually call pkey_alloc() anyway
because the /proc check is inherently racy.

I'm just not sure I see the value in creating a new ABI for it.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Tue, Jul 11, 2017 at 02:57:30PM -0700, Dave Hansen wrote:
> On 07/11/2017 02:51 PM, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> >> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> >>> On 07/05/2017 02:21 PM, Ram Pai wrote:
>  Currently sys_pkey_create() provides the ability to disable read
>  and write permission on the key, at  creation. powerpc  has  the
>  hardware support to disable execute on a pkey as well.This patch
>  enhances the interface to let disable execute  at  key  creation
>  time. x86 does  not  allow  this.  Hence the next patch will add
>  ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
>  specified.
> >>
> >> That leads to the question... How do you tell userspace.
> >>
> >> (apologies if I missed that in an existing patch in the series)
> >>
> >> How do we inform userspace of the key capabilities ? There are at least
> >> two things userspace may want to know already:
> >>
> >>  - What protection bits are supported for a key
> > 
> > the userspace is the one which allocates the keys and enables/disables the
> > protection bits on the key. the kernel is just a facilitator. Now if the
> > use space wants to know the current permissions on a given key, it can
> > just read the AMR/PKRU register on powerpc/intel respectively.
> 
> Let's say I want to execute-disable a region.  Can I use protection
> keys?  Do I do
> 
>   pkey_mprotect(... PKEY_DISABLE_EXECUTE);
> 
> and assume that the -EINVAL is because PKEY_DISABLE_EXECUTE is
> unsupported, or do I do:
> 
> #ifdef __ppc__
>   pkey = pkey_aloc();
>   pkey_mprotect(... PKEY_DISABLE_EXECUTE);
> #else
>   mprotect();
> #endif

on ppc you could do either
pkey = pkey_alloc(..,PKEY_DISABLE_EXECUTE);
pkey_mprotect(...,pkey);

or you can just do the x86 way
mprotect();

> 
> >>  - How many keys exist
> > 
> > There is no standard way of finding this other than trying to allocate
> > as many till you fail.  A procfs or sysfs file can be added to expose
> > this information.
> 
> It's also dynamic.  On x86, you lose a key if you've used the
> execute-only support.  We also reserve the right to steal more in the
> future if we want.

total number of key supported on the architecture is a constant.
How many are reserved by the architecture is also probably known in
advance.
Now how many does the kernel use to reserve for itself is something
the kernel knows too and hence can expose it, though the information
may change dynamically as the kernel reserves and releases the key
based on its internal needs. 

So i think we can expose this informaton through procfs/sysfs and let
the application decide how it wants to use the information.

> 
> >>  - Which keys are available for use by userspace. On PowerPC, the
> >> kernel can reserve some keys for itself, so can the hypervisor. In
> >> fact, they do.
> > 
> > this information can be exposed through /proc or /sysfs
> > 
> > I am sure there will be more demands and requirements as applications
> > start leveraging these feature.
> 
> For 5 bits, I think just having someone run pkey_alloc() in a loop is
> fine.  I don't think we really need to enumerate it in some other way.

-- 
Ram Pai

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Tue, Jul 11, 2017 at 02:57:30PM -0700, Dave Hansen wrote:
> On 07/11/2017 02:51 PM, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> >> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> >>> On 07/05/2017 02:21 PM, Ram Pai wrote:
>  Currently sys_pkey_create() provides the ability to disable read
>  and write permission on the key, at  creation. powerpc  has  the
>  hardware support to disable execute on a pkey as well.This patch
>  enhances the interface to let disable execute  at  key  creation
>  time. x86 does  not  allow  this.  Hence the next patch will add
>  ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
>  specified.
> >>
> >> That leads to the question... How do you tell userspace.
> >>
> >> (apologies if I missed that in an existing patch in the series)
> >>
> >> How do we inform userspace of the key capabilities ? There are at least
> >> two things userspace may want to know already:
> >>
> >>  - What protection bits are supported for a key
> > 
> > the userspace is the one which allocates the keys and enables/disables the
> > protection bits on the key. the kernel is just a facilitator. Now if the
> > use space wants to know the current permissions on a given key, it can
> > just read the AMR/PKRU register on powerpc/intel respectively.
> 
> Let's say I want to execute-disable a region.  Can I use protection
> keys?  Do I do
> 
>   pkey_mprotect(... PKEY_DISABLE_EXECUTE);
> 
> and assume that the -EINVAL is because PKEY_DISABLE_EXECUTE is
> unsupported, or do I do:
> 
> #ifdef __ppc__
>   pkey = pkey_aloc();
>   pkey_mprotect(... PKEY_DISABLE_EXECUTE);
> #else
>   mprotect();
> #endif

on ppc you could do either
pkey = pkey_alloc(..,PKEY_DISABLE_EXECUTE);
pkey_mprotect(...,pkey);

or you can just do the x86 way
mprotect();

> 
> >>  - How many keys exist
> > 
> > There is no standard way of finding this other than trying to allocate
> > as many till you fail.  A procfs or sysfs file can be added to expose
> > this information.
> 
> It's also dynamic.  On x86, you lose a key if you've used the
> execute-only support.  We also reserve the right to steal more in the
> future if we want.

total number of key supported on the architecture is a constant.
How many are reserved by the architecture is also probably known in
advance.
Now how many does the kernel use to reserve for itself is something
the kernel knows too and hence can expose it, though the information
may change dynamically as the kernel reserves and releases the key
based on its internal needs. 

So i think we can expose this informaton through procfs/sysfs and let
the application decide how it wants to use the information.

> 
> >>  - Which keys are available for use by userspace. On PowerPC, the
> >> kernel can reserve some keys for itself, so can the hypervisor. In
> >> fact, they do.
> > 
> > this information can be exposed through /proc or /sysfs
> > 
> > I am sure there will be more demands and requirements as applications
> > start leveraging these feature.
> 
> For 5 bits, I think just having someone run pkey_alloc() in a loop is
> fine.  I don't think we really need to enumerate it in some other way.

-- 
Ram Pai

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Benjamin Herrenschmidt]

On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > Currently sys_pkey_create() provides the ability to disable read
> > > > and write permission on the key, at  creation. powerpc  has  the
> > > > hardware support to disable execute on a pkey as well.This patch
> > > > enhances the interface to let disable execute  at  key  creation
> > > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > > specified.
> > 
> > That leads to the question... How do you tell userspace.
> > 
> > (apologies if I missed that in an existing patch in the series)
> > 
> > How do we inform userspace of the key capabilities ? There are at least
> > two things userspace may want to know already:
> > 
> >  - What protection bits are supported for a key
> 
> the userspace is the one which allocates the keys and enables/disables the
> protection bits on the key. the kernel is just a facilitator. Now if the
> use space wants to know the current permissions on a given key, it can
> just read the AMR/PKRU register on powerpc/intel respectively.

You misunderstand. How does userspace knows on a given system whether
execute permission control is supported for keys ?
> 
> > 
> >  - How many keys exist
> 
> There is no standard way of finding this other than trying to allocate
> as many till you fail.  A procfs or sysfs file can be added to expose
> this information.
> 
> > 
> >  - Which keys are available for use by userspace. On PowerPC, the
> > kernel can reserve some keys for itself, so can the hypervisor. In
> > fact, they do.
> 
> this information can be exposed through /proc or /sysfs
> 
> I am sure there will be more demands and requirements as applications
> start leveraging these feature.
> 
> RP
> > 
> > Cheers,
> > Ben.
> 
> 

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Benjamin Herrenschmidt]

On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > Currently sys_pkey_create() provides the ability to disable read
> > > > and write permission on the key, at  creation. powerpc  has  the
> > > > hardware support to disable execute on a pkey as well.This patch
> > > > enhances the interface to let disable execute  at  key  creation
> > > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > > specified.
> > 
> > That leads to the question... How do you tell userspace.
> > 
> > (apologies if I missed that in an existing patch in the series)
> > 
> > How do we inform userspace of the key capabilities ? There are at least
> > two things userspace may want to know already:
> > 
> >  - What protection bits are supported for a key
> 
> the userspace is the one which allocates the keys and enables/disables the
> protection bits on the key. the kernel is just a facilitator. Now if the
> use space wants to know the current permissions on a given key, it can
> just read the AMR/PKRU register on powerpc/intel respectively.

You misunderstand. How does userspace knows on a given system whether
execute permission control is supported for keys ?
> 
> > 
> >  - How many keys exist
> 
> There is no standard way of finding this other than trying to allocate
> as many till you fail.  A procfs or sysfs file can be added to expose
> this information.
> 
> > 
> >  - Which keys are available for use by userspace. On PowerPC, the
> > kernel can reserve some keys for itself, so can the hypervisor. In
> > fact, they do.
> 
> this information can be exposed through /proc or /sysfs
> 
> I am sure there will be more demands and requirements as applications
> start leveraging these feature.
> 
> RP
> > 
> > Cheers,
> > Ben.
> 
> 

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/11/2017 02:51 PM, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
>>> On 07/05/2017 02:21 PM, Ram Pai wrote:
 Currently sys_pkey_create() provides the ability to disable read
 and write permission on the key, at  creation. powerpc  has  the
 hardware support to disable execute on a pkey as well.This patch
 enhances the interface to let disable execute  at  key  creation
 time. x86 does  not  allow  this.  Hence the next patch will add
 ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
 specified.
>>
>> That leads to the question... How do you tell userspace.
>>
>> (apologies if I missed that in an existing patch in the series)
>>
>> How do we inform userspace of the key capabilities ? There are at least
>> two things userspace may want to know already:
>>
>>  - What protection bits are supported for a key
> 
> the userspace is the one which allocates the keys and enables/disables the
> protection bits on the key. the kernel is just a facilitator. Now if the
> use space wants to know the current permissions on a given key, it can
> just read the AMR/PKRU register on powerpc/intel respectively.

Let's say I want to execute-disable a region.  Can I use protection
keys?  Do I do

pkey_mprotect(... PKEY_DISABLE_EXECUTE);

and assume that the -EINVAL is because PKEY_DISABLE_EXECUTE is
unsupported, or do I do:

#ifdef __ppc__
pkey = pkey_aloc();
pkey_mprotect(... PKEY_DISABLE_EXECUTE);
#else
mprotect();
#endif

>>  - How many keys exist
> 
> There is no standard way of finding this other than trying to allocate
> as many till you fail.  A procfs or sysfs file can be added to expose
> this information.

It's also dynamic.  On x86, you lose a key if you've used the
execute-only support.  We also reserve the right to steal more in the
future if we want.

>>  - Which keys are available for use by userspace. On PowerPC, the
>> kernel can reserve some keys for itself, so can the hypervisor. In
>> fact, they do.
> 
> this information can be exposed through /proc or /sysfs
> 
> I am sure there will be more demands and requirements as applications
> start leveraging these feature.

For 5 bits, I think just having someone run pkey_alloc() in a loop is
fine.  I don't think we really need to enumerate it in some other way.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/11/2017 02:51 PM, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
>>> On 07/05/2017 02:21 PM, Ram Pai wrote:
 Currently sys_pkey_create() provides the ability to disable read
 and write permission on the key, at  creation. powerpc  has  the
 hardware support to disable execute on a pkey as well.This patch
 enhances the interface to let disable execute  at  key  creation
 time. x86 does  not  allow  this.  Hence the next patch will add
 ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
 specified.
>>
>> That leads to the question... How do you tell userspace.
>>
>> (apologies if I missed that in an existing patch in the series)
>>
>> How do we inform userspace of the key capabilities ? There are at least
>> two things userspace may want to know already:
>>
>>  - What protection bits are supported for a key
> 
> the userspace is the one which allocates the keys and enables/disables the
> protection bits on the key. the kernel is just a facilitator. Now if the
> use space wants to know the current permissions on a given key, it can
> just read the AMR/PKRU register on powerpc/intel respectively.

Let's say I want to execute-disable a region.  Can I use protection
keys?  Do I do

pkey_mprotect(... PKEY_DISABLE_EXECUTE);

and assume that the -EINVAL is because PKEY_DISABLE_EXECUTE is
unsupported, or do I do:

#ifdef __ppc__
pkey = pkey_aloc();
pkey_mprotect(... PKEY_DISABLE_EXECUTE);
#else
mprotect();
#endif

>>  - How many keys exist
> 
> There is no standard way of finding this other than trying to allocate
> as many till you fail.  A procfs or sysfs file can be added to expose
> this information.

It's also dynamic.  On x86, you lose a key if you've used the
execute-only support.  We also reserve the right to steal more in the
future if we want.

>>  - Which keys are available for use by userspace. On PowerPC, the
>> kernel can reserve some keys for itself, so can the hypervisor. In
>> fact, they do.
> 
> this information can be exposed through /proc or /sysfs
> 
> I am sure there will be more demands and requirements as applications
> start leveraging these feature.

For 5 bits, I think just having someone run pkey_alloc() in a loop is
fine.  I don't think we really need to enumerate it in some other way.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > Currently sys_pkey_create() provides the ability to disable read
> > > and write permission on the key, at  creation. powerpc  has  the
> > > hardware support to disable execute on a pkey as well.This patch
> > > enhances the interface to let disable execute  at  key  creation
> > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > specified.
> 
> That leads to the question... How do you tell userspace.
> 
> (apologies if I missed that in an existing patch in the series)
> 
> How do we inform userspace of the key capabilities ? There are at least
> two things userspace may want to know already:
> 
>  - What protection bits are supported for a key

the userspace is the one which allocates the keys and enables/disables the
protection bits on the key. the kernel is just a facilitator. Now if the
use space wants to know the current permissions on a given key, it can
just read the AMR/PKRU register on powerpc/intel respectively.

> 
>  - How many keys exist

There is no standard way of finding this other than trying to allocate
as many till you fail.  A procfs or sysfs file can be added to expose
this information.

> 
>  - Which keys are available for use by userspace. On PowerPC, the
> kernel can reserve some keys for itself, so can the hypervisor. In
> fact, they do.

this information can be exposed through /proc or /sysfs

I am sure there will be more demands and requirements as applications
start leveraging these feature.

RP
> 
> Cheers,
> Ben.

-- 
Ram Pai

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Ram Pai]

On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > Currently sys_pkey_create() provides the ability to disable read
> > > and write permission on the key, at  creation. powerpc  has  the
> > > hardware support to disable execute on a pkey as well.This patch
> > > enhances the interface to let disable execute  at  key  creation
> > > time. x86 does  not  allow  this.  Hence the next patch will add
> > > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > > specified.
> 
> That leads to the question... How do you tell userspace.
> 
> (apologies if I missed that in an existing patch in the series)
> 
> How do we inform userspace of the key capabilities ? There are at least
> two things userspace may want to know already:
> 
>  - What protection bits are supported for a key

the userspace is the one which allocates the keys and enables/disables the
protection bits on the key. the kernel is just a facilitator. Now if the
use space wants to know the current permissions on a given key, it can
just read the AMR/PKRU register on powerpc/intel respectively.

> 
>  - How many keys exist

There is no standard way of finding this other than trying to allocate
as many till you fail.  A procfs or sysfs file can be added to expose
this information.

> 
>  - Which keys are available for use by userspace. On PowerPC, the
> kernel can reserve some keys for itself, so can the hypervisor. In
> fact, they do.

this information can be exposed through /proc or /sysfs

I am sure there will be more demands and requirements as applications
start leveraging these feature.

RP
> 
> Cheers,
> Ben.

-- 
Ram Pai

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Benjamin Herrenschmidt]

On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> On 07/05/2017 02:21 PM, Ram Pai wrote:
> > Currently sys_pkey_create() provides the ability to disable read
> > and write permission on the key, at  creation. powerpc  has  the
> > hardware support to disable execute on a pkey as well.This patch
> > enhances the interface to let disable execute  at  key  creation
> > time. x86 does  not  allow  this.  Hence the next patch will add
> > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > specified.

That leads to the question... How do you tell userspace.

(apologies if I missed that in an existing patch in the series)

How do we inform userspace of the key capabilities ? There are at least
two things userspace may want to know already:

 - What protection bits are supported for a key

 - How many keys exist

 - Which keys are available for use by userspace. On PowerPC, the
kernel can reserve some keys for itself, so can the hypervisor. In
fact, they do.

Cheers,
Ben.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Benjamin Herrenschmidt]

On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> On 07/05/2017 02:21 PM, Ram Pai wrote:
> > Currently sys_pkey_create() provides the ability to disable read
> > and write permission on the key, at  creation. powerpc  has  the
> > hardware support to disable execute on a pkey as well.This patch
> > enhances the interface to let disable execute  at  key  creation
> > time. x86 does  not  allow  this.  Hence the next patch will add
> > ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> > specified.

That leads to the question... How do you tell userspace.

(apologies if I missed that in an existing patch in the series)

How do we inform userspace of the key capabilities ? There are at least
two things userspace may want to know already:

 - What protection bits are supported for a key

 - How many keys exist

 - Which keys are available for use by userspace. On PowerPC, the
kernel can reserve some keys for itself, so can the hypervisor. In
fact, they do.

Cheers,
Ben.

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently sys_pkey_create() provides the ability to disable read
> and write permission on the key, at  creation. powerpc  has  the
> hardware support to disable execute on a pkey as well.This patch
> enhances the interface to let disable execute  at  key  creation
> time. x86 does  not  allow  this.  Hence the next patch will add
> ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> specified.
> 
> Signed-off-by: Ram Pai 
> ---
>  include/uapi/asm-generic/mman-common.h |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/include/uapi/asm-generic/mman-common.h 
> b/include/uapi/asm-generic/mman-common.h
> index 8c27db0..bf4fa07 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -74,7 +74,9 @@
>  
>  #define PKEY_DISABLE_ACCESS  0x1
>  #define PKEY_DISABLE_WRITE   0x2
> +#define PKEY_DISABLE_EXECUTE 0x4
>  #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> -  PKEY_DISABLE_WRITE)
> +  PKEY_DISABLE_WRITE  |\
> +  PKEY_DISABLE_EXECUTE)

If you do this, it breaks bisection.  Can you please just do this in one
patch?

Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation

[Dave Hansen]

On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently sys_pkey_create() provides the ability to disable read
> and write permission on the key, at  creation. powerpc  has  the
> hardware support to disable execute on a pkey as well.This patch
> enhances the interface to let disable execute  at  key  creation
> time. x86 does  not  allow  this.  Hence the next patch will add
> ability  in  x86  to  return  error  if  PKEY_DISABLE_EXECUTE is
> specified.
> 
> Signed-off-by: Ram Pai 
> ---
>  include/uapi/asm-generic/mman-common.h |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/include/uapi/asm-generic/mman-common.h 
> b/include/uapi/asm-generic/mman-common.h
> index 8c27db0..bf4fa07 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -74,7 +74,9 @@
>  
>  #define PKEY_DISABLE_ACCESS  0x1
>  #define PKEY_DISABLE_WRITE   0x2
> +#define PKEY_DISABLE_EXECUTE 0x4
>  #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> -  PKEY_DISABLE_WRITE)
> +  PKEY_DISABLE_WRITE  |\
> +  PKEY_DISABLE_EXECUTE)

If you do this, it breaks bisection.  Can you please just do this in one
patch?