On Mon, Apr 22, 2024 at 02:11:05PM +0200, Arnd Bergmann wrote:
On Mon, Apr 22, 2024, at 11:40, Mark Rutland wrote:
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.
I tested with the old binutils versions I have here and found that anything that supports v8.3 also understands pacga, but '.arch_extension pauth' only works in binutils-2.35 and higher, presumably because it started out as a v8.3+ feature but was later turned into an optional extension for all versions.
Since there is a Kconfig check for armv8.3-a support already, I think it's safe to just drop the .arch_extension pauth.
That'll be safe, but it does mean that we'd need to *not* support pointer auth for nested virt when we have a toolchain for which CONFIG_AS_HAS_ARMV8_3=n, unless our minimum supported AS supports ARMv8.3.
If our minimum supported AS *doesn't* support ARMv8.3, then we'd either need a new Kconfig symbol for NV_PAUTH support, or make CONFIG_ARM64_PTR_AUTH depend upon CONFIG_AS_HAS_ARMV8_3.
AFAICT our options are:
(a) Manually assembly PACGA
(b) Change CONFIG_ARM64_PTR_AUTH to depend upon CONFIG_AS_HAS_ARMV8_3=y
(c) Add and use new Kconfig symbol for NV PAUTH, dependent upon CONFIG_AS_HAS_ARMV8_3=y
(d) Bump the minimum supported version of AS so that we can depend upon ARMv8.3 support, and just open-code the ".arch armv8.3-a" in the NV pauth code.
... and maybe some variations on that.
Mark.