linux-kernel - Re: gcc-8: arm64/kvm/pauth.: Error: unknown architectural extension `pauth'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 22 Apr 2024 20:44:37 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Mark Rutland" <mark.rutland@....com>
Cc: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 "open list" <linux-kernel@...r.kernel.org>,
 "Linux ARM" <linux-arm-kernel@...ts.infradead.org>,
 lkft-triage@...ts.linaro.org,
 "Linux Regressions" <regressions@...ts.linux.dev>,
 "Anders Roxell" <anders.roxell@...aro.org>, "Marc Zyngier" <maz@...nel.org>,
 joey.gouly@....com, "Oliver Upton" <oliver.upton@...ux.dev>
Subject: Re: gcc-8: arm64/kvm/pauth.: Error: unknown architectural extension `pauth'

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