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]
Message-Id: <24db3769-9b50-4cf9-b5f6-a8cc068f064d@app.fastmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ