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

From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	libc-alpha@sourceware.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Linux API <linux-api@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)
Date: Tue, 17 Nov 2020 18:39:13 +0000	[thread overview]
Message-ID: <20201117183911.GI15033@arm.com> (raw)
In-Reply-To: <CAMn1gO7a-uyP93P4KapbsXy1+HRSuJR4r_kyy0_-FCY69qO_nA@mail.gmail.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