Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

On Sun, 6 May 2018 13:10:43 -0700
Ram Pai [off-list ref] wrote:

On Sat, May 05, 2018 at 02:39:56PM +0200, Michal Such=C3=A1nek wrote:

quoted

On Fri, 4 May 2018 14:45:07 -0700
Ram Pai [off-list ref] wrote:
 =20

quoted

On Fri, May 04, 2018 at 02:31:10PM -0700, Dave Hansen wrote: =20

quoted

On 05/04/2018 02:26 PM, Michal Such=C3=A1nek wrote:   =20

quoted

If it is not ok to change permissions of pkey 0 is it ok to
free it?   =20

=20
It's pretty much never OK to free it on x86 or ppc.  But, we're
not going to put code in to keep userspace from shooting itself
in the foot, at least on x86.   =20

=20
and on powerpc aswell. =20

=20
But once it's free it can be re-allocated. So you are moving the
special-casing from free code to code dealing with allocation. =20

=20
Actually if an application frees key-0, it has potentially opened up a
can-of-worms. It could step on anything that explodes.=20
=20
Its choice between imposing policies on an application v/s freeing it
up to choose its own policy. I think the kernel should impose some
form of mild-policy. But others think there should be none.

It is a problem of the application when it frees a key it still needs.
I am not for or against allowing that. The problem is with the
interface change once the key is freed.

=20

quoted

=20
If you want something like allocate_exec_only_pkey then the function
(either in kernel or in userspace) needs to make sure it is not
getting/requesting key 0 on powerpc. =20

=20
Yes. makes sense. I will put in some checks towards that.

Suppose an application is adapted to take advantage of freeing key
0, perhaps to revoke access to any code and data used at runtime
initialization which is not longer needed.=20

As I understand it with the proposed change any address range not
associated with non-default key becomes inaccessible and key 0 becomes
available for allocation again. This is fine on x86 where key 0 is
fully functional.=20

However, on powerpc the application now has key 0 available and it is
not fully a fully functional key. So the application now needs to check
that the key it is allocating is not key 0. Otherwise further key
operations may unexpectedly fail.

To prevent this I would suggest

a) do not allow allocating key 0. If it is freed it becomes reserved

b) never expose key 0 to applications. Allocate key 2 as the default
key and present the key numbers with an offset to userspace so key 2
appears as key 0 to user applications.

Thanks

Michal