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

[Peter Collingbourne]

On Tue, Nov 17, 2020 at 10:14 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
>
> 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 at 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.

For compatibility with previous kernel versions all keys are enabled
by default at process startup. But I agree it would be useful to point
it 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.)

My understanding is that it was considered too expensive to do without
a use case, but we did come up with one. In general we only need to
update the system register on process switch as well as on entry/exit
if we need to disable IA which is also needed by in-kernel PAC. I did
benchmark a variant of the code sequences on existing non-PAC HW [1]
which showed that the entry/exit overhead in the common case where IA
is left enabled is expected to be low. But with the new Apple chips I
think it should be possible to benchmark the real entry/exit code
sequences on supporting HW in the enabled and disabled cases.

Peter

[1] https://lore.kernel.org/linux-arm-kernel/CAMn1gO7HCJiXEzDvBb-=T7znATqyaxE_t-zezqKL0dyXRCG-nQ@mail.gmail.com/