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

On Tue, 8 May 2018 09:38:01 -0700
Ram Pai [off-list ref] wrote:

On Mon, May 07, 2018 at 01:21:49PM +0200, Michal Such=C3=A1nek wrote:

quoted

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

quoted

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

 =20

quoted

quoted

quoted

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

...

quoted

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
=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. =20

=20
The above sentence is difficult to parse. I think what you are saying
is -- Any address range associated with key-0 become inaccessible if
key-0 is freed.  Is that a correct simplification of the above
	statement?
=20
Assuming I got it right -- =20
=20
	Yes. key-0 when freed becomes available for allocation again.
	No. When key-0 is freed any address range
associated with key-0 will continue to be accessible.  It was
accessible to begin with and will continue to be accessible.  It was
accessible, because kernel; during task-creation, never disables any
permissions on key-0, and also never lets userspace disable any
permissions on key-0.

Oh, right. The result of freeing a used key is not defined. When it is
not defined expecting a sane result is too much.

=20
The problem arises, when key-0 gets reallocated at a later time. If
the key-0 at that point(during reallocation) is treated like any
other key; allowing userspace to change its permissions, it can
explode on access to any page associated with key-0. (BTW: almost
everything is associated with key-0 by default).
=20

quoted

This is fine on x86 where key 0 is fully functional.  =20

=20

quoted

=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.
=20
To prevent this I would suggest
=20
a) do not allow allocating key 0. If it is freed it becomes
reserved =20

=20
Certainly yes. We never promised any particular key to the user
space. So not returning key-0 during allocation should break no
semantics.
=20

quoted

=20
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. =20

=20
this is complicated. offseting the number is not easy. if kernel
has allocated key-2 and tells the user space to use key-0, userspace
will use bit-0 and bit-1 of the AMR register to program the
permissions on the key, and cpu will start applying those changes on
key-0. Basically kernel, userspace and cpu will be out-of-sync. This
is possible if the userspace uses a shift-aware library function to
program the AMR. BTW: A library function integrated into glibc is yet
to be defined AFAICK.

If userspace can program the hardware directly then it is not possible
to lie about the key numbers, unfortunately. An alternative is to
reserve a different key for the kernel so applications get default key
as 0 and can set permissions on it on any platform.

How is the application denied setting the permissions on key 0 if it
can program the register directly?

Thanks

Michal