[RFC] aarch64: Add support for memory protection keys

[Szabolcs Nagy]

The 06/12/2024 17:04, Florian Weimer wrote:
> * yury khrustalev:
> 
> > +  /* Only the following mapping between POR permission bits (4 bits)
> > +     and PKEY flags is guaranteed:
> > +
> > +       -WXR
> > +       0010       => PKEY_DISABLE_ACCESS (execute only)
> > +       0011       => PKEY_DISABLE_WRITE (read-execute)
> > +       0111       => 0 (no restrictions, read-write-execute)
> > +       otherwise  => undefined behavior
> > +
> > +     Note that pkey_set and pkey_alloc would only set these specific
> > +     values.  */
> > +
> > +  if (perm == S1POE_PERM_X)
> > +    return PKEY_DISABLE_ACCESS;
> > +  if (perm == S1POE_PERM_RX)
> > +    return PKEY_DISABLE_WRITE;
> > +  if (perm == S1POE_PERM_RWX)
> > +    return 0; // no restrictions
> > +  return PKEY_DISABLE_ACCESS; // undefined behavior
> 
> POWER has the same translation issue.  I suggest to get additional
> constants defined by the kernel, whether it's PKEY_DISABLE_READ and
> PKEY_DISABLE_EXEC or the full set of PKEY_ENABLE_* constant may not
> matter.
> 
> PKEY_DISABLE_ACCESS really should have been PKEY_DISABLE_READ |
> PKEY_DISABLE_WRITE, but unfortunately that's not how the x86 hardware
> works.

i assume existing aarch64 binaries using pkey would always fail
so we don't have a linux abi requirement to use the constants as
defined today.

i'm not sure if linux generic code relies on the exact values,
but we can discuss changing the values with linux devs.

either way only the disable access/write macros will be portable.

> 
> There are also some concerns that pkey_set/pkey_get are impractical as
> an interface because of the function call overhead, but that's a
> separate matter.
> 

if user code is allowed to change the permission register directly
then pkey_get has a problem if the setting is an uknown value.
on aarch64, 0b1xxx permission values are reserved for future use
so this can happen.

i guess we can document that setting such a value is ub for now.