On Tue, Jan 26, 2021 at 4:49 AM Will Deacon <will@xxxxxxxxxx> 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@xxxxxxxxxx> > > Reviewed-by: Dave Martin <Dave.Martin@xxxxxxx> > > 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
