On Mon, Apr 22, 2024 at 11:25:25AM +0200, Arnd Bergmann wrote:
On Mon, Apr 22, 2024, at 11:13, Mark Rutland wrote:
On Mon, Apr 22, 2024 at 02:04:43PM +0530, Naresh Kamboju wrote: Given the minimum supported toolchain comes with an assembler that doesn't necessarily support ARMv8.3, I reckon we'll either have to make NV pauth support depend upon AS_HAS_ARMV8_3, or manually assemble the PACGA instruction.
I suspect the latter is the better option.
The .config linked from the report shows
CONFIG_AS_VERSION=23101 CONFIG_ARM64_PTR_AUTH_KERNEL=y CONFIG_AS_HAS_ARMV8_3=y
So it gets detected as supporting ARMv8.3. Is this the wrong conditional to check, or does it get misdetected for an unsupported assembler?
I suspect that means the 'pauth' arch extension was added after armv8.3 support, and the assembler supports `-march=armv8.3-a` but does not support `.arch_extension pauth`. So for this code, it'd be wrong to check for AS_HAS_ARMV8_3, unless we used `.march armv8.3-a`, but even then that'd still mean configurations where we couldn't support this code.
I reckon manually assembing the PACGA is the best thing to do; that sidesteps the need for either `.arch_extension pauth` or `.march armv8.3-a`, and aligns with what we do for CONFIG_ARM64_PTR_AUTH=y generally.
Elsewhere in the kernel where we check for CONFIG_AS_HAS_ARMV8_3, we rely on ARM64_ASM_PREAMBLE containing `.arch armv8.3-a` or a later version that implies the presence of ARMv8.3-A instructions, and so pauth usage elsewhere is fine.
Mark.