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

From: Peter Collingbourne <pcc@google.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kostya Serebryany <kcc@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Linux API <linux-api@vger.kernel.org>,
	Will Deacon <will@kernel.org>,
	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 11:05:54 -0800	[thread overview]
Message-ID: <CAMn1gO7DMx7ty3+09M49wAs-JCEH1H2T13-VxKXCeUz0oGj=Wg@mail.gmail.com> (raw)
In-Reply-To: <20201118175539.GH6882@arm.com>

On Wed, Nov 18, 2020 at 9:55 AM Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Tue, Oct 13, 2020 at 10:51:06PM -0700, Peter Collingbourne wrote:
> > 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.
>
> Does this boil down to using the B key(s) to sign pointers that flow
> across library boundaries?

Right, the B key or whichever I key you select as part of the
interprocedural ABI (most likely B to avoid the kernel's entry/exit
slow path if it needs to be disabled).

> ld.so would then need a control to turn off the B key off if, say,
> the main program or some random library it uses hasn't been rebuilt
> to enable this signing.
>
> (I think we discussed this before, but I keep forgetting the exact
> rationale.)

See [1] where we discussed this before.

> > 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.
>
> We probably need a new program property in ELF to describe this.

There is a draft PAuth ABI [2] which will specify how the feature
works in ELF. I believe that the specification will include details of
how the ELF markings are going to work.

> Currently, there is GNU_PROPERTY_AARCH64_FEATURE_1_PAC, which does not
> specify a key -- but I think it could be defined retrospectively to
> apply to just the APIA key, say.
>
> This raises the question of whether the kernel should actually turn the
> keys on or off based on these flags.  For historical compatibility,
> probably not -- but we could perhaps do that for the B key since the ABI
> for use of the B key is entirely unstandardised so far.

I would be against having the kernel read any ELF properties at this
point. All of the processing can be done in the dynamic loader, and
ELF properties are strictly less powerful than having the dynamic
loader decide what to do. It's not enough to look at the main
executable anyway because you would also need to read the recursive
dynamic libraries and that's a task better done in userspace.
Userspace may also require more complex logic than what can be
expressed with ELF properties (for example, on Android we would need
the same executable to be launched twice, once with keys enabled and
once with keys disabled). If we do anything at all it should probably
be based on whatever we come up with for the PAuth ABI which hasn't
been finalized yet.

> I'll take a look at the patch tomorrow -- my brain isn't functioning
> right now.

Thanks.

Peter

[1] https://lore.kernel.org/linux-arm-kernel/CAMn1gO5JV4-xDO0TAJcY8DmNVgZb_sBH=RUEQY1gTUmmFPGHqQ@mail.gmail.com/
[2] https://github.com/ARM-software/abi-aa/blob/master/pauthabielf64/pauthabielf64.rst