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

[Michal Suchánek]

On Tue, 8 May 2018 09:38:01 -0700
Ram Pai <linuxram at us.ibm.com> wrote:

> On Mon, May 07, 2018 at 01:21:49PM +0200, Michal Suchánek wrote:
> > On Sun, 6 May 2018 13:10:43 -0700
> > Ram Pai <linuxram at us.ibm.com> wrote:
> >   
> > > On Sat, May 05, 2018 at 02:39:56PM +0200, Michal Suchánek wrote:  
> > > > On Fri, 4 May 2018 14:45:07 -0700
> > > > Ram Pai <linuxram at us.ibm.com> wrote:
...
> > 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. 
> > 
> > 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.  
> 
> 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?
> 
> Assuming I got it right --  
> 
> 	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.

> 
> 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).
> 
> > This is fine on x86 where key 0 is fully functional.   
> 
> > 
> > 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  
> 
> Certainly yes. We never promised any particular key to the user
> space. So not returning key-0 during allocation should break no
> semantics.
> 
> > 
> > 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.  
> 
> 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