From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
lkft-triage@lists.linaro.org,
Linux Regressions <regressions@lists.linux.dev>,
Anders Roxell <anders.roxell@linaro.org>,
Marc Zyngier <maz@kernel.org>,
joey.gouly@arm.com, Oliver Upton <oliver.upton@linux.dev>
Subject: Re: gcc-8: arm64/kvm/pauth.: Error: unknown architectural extension `pauth'
Date: Mon, 22 Apr 2024 18:20:40 +0100 [thread overview]
Message-ID: <ZiacX2iNP_bI884s@FVFF77S0Q05N> (raw)
In-Reply-To: <df782e40-95bf-4f8e-96c8-355ff0109e3a@app.fastmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
lkft-triage@lists.linaro.org,
Linux Regressions <regressions@lists.linux.dev>,
Anders Roxell <anders.roxell@linaro.org>,
Marc Zyngier <maz@kernel.org>,
joey.gouly@arm.com, Oliver Upton <oliver.upton@linux.dev>
Subject: Re: gcc-8: arm64/kvm/pauth.: Error: unknown architectural extension `pauth'
Date: Mon, 22 Apr 2024 18:20:40 +0100 [thread overview]
Message-ID: <ZiacX2iNP_bI884s@FVFF77S0Q05N> (raw)
In-Reply-To: <df782e40-95bf-4f8e-96c8-355ff0109e3a@app.fastmail.com>
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-22 17:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 8:34 gcc-8: arm64/kvm/pauth.: Error: unknown architectural extension `pauth' Naresh Kamboju
2024-04-22 8:34 ` Naresh Kamboju
2024-04-22 9:13 ` Mark Rutland
2024-04-22 9:13 ` Mark Rutland
2024-04-22 9:25 ` Arnd Bergmann
2024-04-22 9:25 ` Arnd Bergmann
2024-04-22 9:40 ` Mark Rutland
2024-04-22 9:40 ` Mark Rutland
2024-04-22 12:11 ` Arnd Bergmann
2024-04-22 12:11 ` Arnd Bergmann
2024-04-22 17:20 ` Mark Rutland [this message]
2024-04-22 17:20 ` Mark Rutland
2024-04-22 18:44 ` Arnd Bergmann
2024-04-22 18:44 ` Arnd Bergmann
2024-04-22 22:58 ` Marc Zyngier
2024-04-22 22:58 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiacX2iNP_bI884s@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=maz@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=oliver.upton@linux.dev \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.