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

From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Peter Collingbourne <pcc@google.com>,
	Florian Weimer <fw@deneb.enyo.de>,
	libc-alpha@sourceware.org, 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: Wed, 18 Nov 2020 13:31:21 +0000	[thread overview]
Message-ID: <20201118133121.GA20578@arm.com> (raw)
In-Reply-To: <X7UUoFcmtuHEhoz9@trantor>

The 11/18/2020 12:33, Catalin Marinas wrote:
> 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).

ah ok. i probably incorrectly thought that toggling that sys
register bit is too much overhead at kernel entry so assumed
we cannot have PAC off by default or set per process.

(i think with the proposed prctl it's possible to disable PAC
at early ld.so startup and reenable it before calling into the
main exe entry code, if we ever need to disable PAC-RET.)

i assume thread creation/fork inherits the setting but exec
does not (this is another point that may be worth adding to
the documentation).

if we run into issues in userspace with PAC then a prctl that
can be inherited across exec is a possible workaround (so PAC
can be disabled for an entire process tree).

> 
> > > 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*.

ok. thanks.