[PATCH 2/3] arm64: use XPACLRI to strip PAC

[Will Deacon]

On Tue, Mar 14, 2023 at 04:20:43PM +0000, Mark Rutland wrote:
> Currently we strip the PAC from pointers using C code, which requires
> generating bitmasks, and conditionally clearing/setting bits depending
> on bit 55. We can do better by using XPACLRI directly.
> 
> When the logic was originally written to strip PACs from user pointers,
> contemporary toolchains used for the kernel had assemblers which were
> unaware of the PAC instructions. As stripping the PAC from userspace
> pointers required unconditional clearing of a fixed set of bits (which
> could be performed with a single instruction), it was simpler to
> implement the masking in C than it was to make use of XPACI or XPACLRI.
> 
> When support for in-kernel pointer authentication was added, the
> stripping logic was extended to cover TTBR1 pointers, requiring several
> instructions to handle whether to clear/set bits dependent on bit 55 of
> the pointer.
> 
> These days, all supported toolchains have assemblers which are aware of
> the XPACI and XPACLRI instructions, and contemporary compilers use
> XPACLRI to strip the PAC in __builtin_return_address().

I'm struggling slightly with the reasoning here... presumably there are
_still_ assemblers out there which don't support XPACLRI, so what happens
if somebody tries to build the kernel with one? Is your argument that
the compiler itself is going to generate XPACLRI in the builtin so we're
no worse rolling it ourselves?

If so, it still feels like a step backwards from where we are today (i.e.
we don't require the assembler support) and failing the build due to a
assembler error rather than a Kconfig version check and a helpful
diagnostic is pretty horrible.

Will