On Tue, 8 May 2018 09:38:01 -0700 Ram Pai <linux...@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 <linux...@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 <linux...@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
