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

Catalin Marinas catalin.marinas@arm.com
Wed Nov 18 12:33:36 GMT 2020


On Tue, Nov 17, 2020 at 06:39:13PM +0000, Szabolcs Nagy wrote:
> 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?

I think the past discussion we had was around enabling PAC for kernel
while disabling it for user. The hardware doesn't give us separate bits,
so Peter's patch toggles them on kernel entry/return, with some overhead
given by the MSR+ISB (to be added).

> > 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)

The bits that we can't toggle easily have the comment "This field is
permitted to be cached in the TLB" in the ARM ARM. Luckily, it's not the
case for EnI*.

-- 
Catalin


More information about the Libc-alpha mailing list