On Mon, Apr 22, 2024, at 19:20, Mark Rutland wrote:
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:
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.
Right, I misread the current Kconfig logic and assumed that we already do b), but it's conly CONFIG_ARM64_PTR_AUTH_KERNEL that depends on CONFIG_AS_HAS_ARMV8_3, not the more global CONFIG_ARM64_PTR_AUTH.
I think any of the above would be fine. I see that binutils-2.28 was the first version to include armv8.3-a support back in 2016. The only distros that are old enough to ship something older than that (rhel 7, sles 12, debian 8) also ship with a gcc version that no longer builds the kernel, so doing b) would be the minimum effort fix and still have very little risk of anyone having to turn it off.
Arnd