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

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 11/17/2020 10:17, Peter Collingbourne via Libc-alpha wrote:
> On Tue, Nov 17, 2020 at 9:48 AM Florian Weimer <fw@deneb.enyo.de> 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?
> 
> See e.g. the documentation for SCTLR_EL1.EnIA [1] for details. There
> are also enable bits for the other three keys.

i think it was insufficiently clear in the architecture
spec how that can be context switched. (but it probably
changed)

> If you can avoid creating function pointers before the loader has
> finished recursively scanning all libraries, and the ABI uses
> different keys for function pointers and return addresses, you may be
> able to get away with making the decision in the loader. The idea is

glibc currently only supports pac-ret, so if we enable
or disable pac keys it would be for pac-ret.

(i.e. we would need to do the enable/disable logic in
the dynamic linker entry code before c code is executed)

> that you would disable the function pointer key and leave the return
> address key enabled. This would also have the advantage of at least
> providing return address protection for some libraries if function
> pointer protection can't be enabled.
> 
> > There is also an issue with LD_AUDIT, where we run user-supplied code
> > (which might be PAC-compatible) before loading code that is not.  I
> > guess we could disable PAC by default in LD_AUDIT mode (which is
> > unusual, no relation to the kernel audit subsystem).
> 
> Yes, LD_AUDIT may be difficult to deal with if it can influence which
> libraries are loaded at startup. I agree that LD_AUDIT should disable
> PAC by default.
> 
> Peter
> 
> [1] https://developer.arm.com/docs/ddi0601/d/aarch64-system-registers/sctlr_el1#EnIA_31