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

[Dave Martin]

On Tue, Nov 17, 2020 at 06:48:16PM +0100, Florian Weimer wrote:
> * Peter Collingbourne:
> 
> > 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.
> 
> I thought that the silicon did not support this?
> 
> What exactly does this switch on and off?  The signing itself (so that
> the bits are zero again), or just the verification?
> 
> I do not know how easy it will be to adjust the glibc dynamic linker
> to this because I expect it to use PAC instructions itself.  (It is an
> interesting target, I suppose, so this makes sense to me.)  The loader
> code used for initial process setup and later dlopen is the same.
> Worst case, we could compile the loader twice.

I don't think this would matter if only the B key is turned on and off,
since the compiler and libc should only be using the A key (or no key at
all) when built standard compiler options.

IIUC the default compiler options when using PAC will only use the
A key, and only use the PAC instructions that execute as NOPs when the
affected key is disabled (precisely so that the code still runs on non-
PAC supporting hardware).  But you can't simply flip it on and off while
there are function frames on the stack that assume it's either on or off.


However, the kernel interface should not assume any particular userspace
environment, so the controls offered should be general.  There are
plenty of other prctl()s (as well as regular syscalls) that will confuse
or break glibc; this is not really any different.

[...]

Cheers
---Dave