[PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)

[Szabolcs Nagy]

The 11/17/2020 17:29, Catalin Marinas wrote:
> Adding Szabolcs and libc-alpha. The original patch below and also here:
> 
> https://lore.kernel.org/r/20201014055106.25164-1-pcc@google.com
> 
> The patch looks fine to me but I'd like the glibc community to confirm
> that they are happy with this ABI addition. I'd also like Dave Martin to
> ack the patch since he was involved in the discussion for v1.
> 
> Thanks.
> 
> Catalin
> 
> On Tue, Oct 13, 2020 at 10:51:06PM -0700, Peter Collingbourne wrote:
> > This prctl allows the user program to control which PAC keys are enabled
> > in a particular task. The main reason why this is useful is to enable a
> > userspace ABI that uses PAC to sign and authenticate function pointers
> > and other pointers exposed outside of the function, while still allowing
> > binaries conforming to the ABI to interoperate with legacy binaries that
> > do not sign or authenticate pointers.
> > 
> > The idea is that a dynamic loader or early startup code would issue
> > this prctl very early after establishing that a process may load legacy
> > binaries, but before executing any PAC instructions.
> > 
> > Signed-off-by: Peter Collingbourne <pcc@google.com>
> > Link: https://linux-review.googlesource.com/id/Ibc41a5e6a76b275efbaa126b31119dc197b927a5
> > ---
> > This patch must be applied on top of Catalin's MTE series:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/mte
> > 
> > Alternatively the series with this patch on top may be
> > downloaded from Gerrit by following the link above.
...
> > +Enabling and disabling keys
> > +---------------------------
> > +
> > +The prctl PR_PAC_SET_ENABLED_KEYS allows the user program to control which
> > +PAC keys are enabled in a particular task. It takes two arguments, the
> > +first being a bitmask of PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY
> > +and PR_PAC_APDBKEY specifying which keys shall be affected by this prctl,
> > +and the second being a bitmask of the same bits specifying whether the key
> > +should be enabled or disabled. For example::
> > +
> > +  prctl(PR_PAC_SET_ENABLED_KEYS,
> > +        PR_PAC_APIAKEY | PR_PAC_APIBKEY | PR_PAC_APDAKEY | PR_PAC_APDBKEY,
> > +        PR_PAC_APIBKEY, 0, 0);
> > +
> > +disables all keys except the IB key.
> > +
> > +The main reason why this is useful is to enable a userspace ABI that uses PAC
> > +instructions to sign and authenticate function pointers and other pointers
> > +exposed outside of the function, while still allowing binaries conforming to
> > +the ABI to interoperate with legacy binaries that do not sign or authenticate
> > +pointers.
> > +
> > +The idea is that a dynamic loader or early startup code would issue this
> > +prctl very early after establishing that a process may load legacy binaries,
> > +but before executing any PAC instructions.

which keys are enabled by default when HWCAP_PACA is
set in AT_HWCAPS ? i think that would be useful to
point out here.

per process enable/disable was deemed costly to do when
pac support was added, did this change? (i'm happy if it
did, because even without a new PAC specific pointer ABI,
plain PAC-RET can cause problems if a process tries to do
its own DWARF unwinding but does not understand the new
opcode that toggles PAC status of the return address,
possibly in a third party library, so a way to opt-out of
PAC is useful. currently it's a kernel config option and
system wide on or off.)