[PATCH v6 2/3] arm64: Introduce prctl(PR_PAC_{SET, GET}_ENABLED_KEYS)

[Peter Collingbourne]

On Tue, Jan 26, 2021 at 4:49 AM Will Deacon <will at kernel.org> wrote:
>
> On Tue, Dec 29, 2020 at 10:59:14PM -0800, Peter Collingbourne wrote:
> > This change introduces a prctl that 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.
> >
> > This change adds a small amount of overhead to kernel entry and exit
> > due to additional required instruction sequences.
> >
> > On a DragonBoard 845c (Cortex-A75) with the powersave governor, the
> > overhead of similar instruction sequences was measured as 4.9ns when
> > simulating the common case where IA is left enabled, or 43.7ns when
> > simulating the uncommon case where IA is disabled. These numbers can
> > be seen as the worst case scenario, since in more realistic scenarios
> > a better performing governor would be used and a newer chip would be
> > used that would support PAC unlike Cortex-A75 and would be expected
> > to be faster than Cortex-A75.
> >
> > On an Apple M1 under a hypervisor, the overhead of the entry/exit
> > instruction sequences introduced by this patch was measured as 0.3ns
> > in the case where IA is left enabled, and 33.0ns in the case where
> > IA is disabled.
> >
> > Signed-off-by: Peter Collingbourne <pcc at google.com>
> > Reviewed-by: Dave Martin <Dave.Martin at arm.com>
> > Link: https://linux-review.googlesource.com/id/Ibc41a5e6a76b275efbaa126b31119dc197b927a5
>
> [...]
>
> > diff --git a/arch/arm64/kernel/pointer_auth.c b/arch/arm64/kernel/pointer_auth.c
> > index adb955fd9bdd..f03e5bfe4490 100644
> > --- a/arch/arm64/kernel/pointer_auth.c
> > +++ b/arch/arm64/kernel/pointer_auth.c
> > @@ -46,3 +46,65 @@ int ptrauth_prctl_reset_keys(struct task_struct *tsk, unsigned long arg)
> >
> >       return 0;
> >  }
> > +
> > +static u64 arg_to_enxx_mask(unsigned long arg)
> > +{
> > +     u64 sctlr_enxx_mask = 0;
> > +
> > +     WARN_ON(arg & ~PR_PAC_ENABLED_KEYS_MASK);
> > +     if (arg & PR_PAC_APIAKEY)
> > +             sctlr_enxx_mask |= SCTLR_ELx_ENIA;
> > +     if (arg & PR_PAC_APIBKEY)
> > +             sctlr_enxx_mask |= SCTLR_ELx_ENIB;
> > +     if (arg & PR_PAC_APDAKEY)
> > +             sctlr_enxx_mask |= SCTLR_ELx_ENDA;
> > +     if (arg & PR_PAC_APDBKEY)
> > +             sctlr_enxx_mask |= SCTLR_ELx_ENDB;
> > +     return sctlr_enxx_mask;
> > +}
> > +
> > +int ptrauth_set_enabled_keys(struct task_struct *tsk, unsigned long keys,
> > +                          unsigned long enabled)
> > +{
> > +     u64 sctlr = tsk->thread.sctlr_user;
> > +
> > +     if (!system_supports_address_auth())
> > +             return -EINVAL;
> > +
> > +     if (is_compat_thread(task_thread_info(tsk)))
> > +             return -EINVAL;
> > +
> > +     if ((keys & ~PR_PAC_ENABLED_KEYS_MASK) || (enabled & ~keys))
> > +             return -EINVAL;
> > +
> > +     sctlr &= ~arg_to_enxx_mask(keys);
> > +     sctlr |= arg_to_enxx_mask(enabled);
> > +     if (tsk == current)
> > +             set_task_sctlr_el1(sctlr);
> > +     else
> > +             tsk->thread.sctlr_user = sctlr;
>
> Who synchronizes all these modifications to 'sctlr_user'? Seems like it gets
> hit by two independent prctl()s as well as ptrace.

The prctls can only affect the current task, so I believe that they
are naturally synchronized (since a task cannot run on multiple CPUs
at once as far as I'm aware). As for ptrace, I believe the tracee must
be stopped in order for the tracer to issue PTRACE_SETREGS (so it
wouldn't be able to issue prctls of its own) and a process can only
have one tracer at a time, so there is again natural synchronization.

Peter