* [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
@ 2022-03-02 16:54 ` Mark Brown
0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2022-03-02 16:54 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, Mark Brown
We support building the kernel with archaic versions of binutils which
had some confusion regarding how instructions should be encoded for .inst
which we work around with the __emit_inst() macro. Unfortunately we have
not consistently used this macro, one of the places where it's missed being
the macros that manually encode v8.2 crypto instructions. This means that
kernels built with such toolchains have never supported use of the affected
instructions correctly.
Since these toolchains are very old (some idle research suggested 2015
era) it seems more sensible to just refuse to build v8.2 crypto support
with them, in the unlikely event that someone has a need to use such a
toolchain to build a kernel which will run on a system with v8.2 crypto
support they can always fix this properly but it seems more likely that
we will deprecate support for these toolchains and remove __emit_inst()
before that happens.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/crypto/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 2a965aa0188d..90dd62d46739 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -32,12 +32,14 @@ config CRYPTO_SHA2_ARM64_CE
config CRYPTO_SHA512_ARM64_CE
tristate "SHA-384/SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_HASH
select CRYPTO_SHA512_ARM64
config CRYPTO_SHA3_ARM64
tristate "SHA3 digest algorithm (ARMv8.2 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_HASH
select CRYPTO_SHA3
@@ -50,6 +52,7 @@ config CRYPTO_SM3_ARM64_CE
config CRYPTO_SM4_ARM64_CE
tristate "SM4 symmetric cipher (ARMv8.2 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_ALGAPI
select CRYPTO_LIB_SM4
--
2.30.2
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
@ 2022-03-02 16:54 ` Mark Brown
0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2022-03-02 16:54 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon
Cc: Ard Biesheuvel, linux-crypto, linux-arm-kernel, Mark Brown
We support building the kernel with archaic versions of binutils which
had some confusion regarding how instructions should be encoded for .inst
which we work around with the __emit_inst() macro. Unfortunately we have
not consistently used this macro, one of the places where it's missed being
the macros that manually encode v8.2 crypto instructions. This means that
kernels built with such toolchains have never supported use of the affected
instructions correctly.
Since these toolchains are very old (some idle research suggested 2015
era) it seems more sensible to just refuse to build v8.2 crypto support
with them, in the unlikely event that someone has a need to use such a
toolchain to build a kernel which will run on a system with v8.2 crypto
support they can always fix this properly but it seems more likely that
we will deprecate support for these toolchains and remove __emit_inst()
before that happens.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/crypto/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 2a965aa0188d..90dd62d46739 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -32,12 +32,14 @@ config CRYPTO_SHA2_ARM64_CE
config CRYPTO_SHA512_ARM64_CE
tristate "SHA-384/SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_HASH
select CRYPTO_SHA512_ARM64
config CRYPTO_SHA3_ARM64
tristate "SHA3 digest algorithm (ARMv8.2 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_HASH
select CRYPTO_SHA3
@@ -50,6 +52,7 @@ config CRYPTO_SM3_ARM64_CE
config CRYPTO_SM4_ARM64_CE
tristate "SM4 symmetric cipher (ARMv8.2 Crypto Extensions)"
depends on KERNEL_MODE_NEON
+ depends on !BROKEN_GAS_INST
select CRYPTO_ALGAPI
select CRYPTO_LIB_SM4
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
2022-03-02 16:54 ` Mark Brown
@ 2022-03-03 7:26 ` Ard Biesheuvel
-1 siblings, 0 replies; 8+ messages in thread
From: Ard Biesheuvel @ 2022-03-03 7:26 UTC (permalink / raw)
To: Mark Brown, Marc Zyngier
Cc: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon,
Linux Crypto Mailing List, Linux ARM
On Wed, 2 Mar 2022 at 16:54, Mark Brown <broonie@kernel.org> wrote:
>
> We support building the kernel with archaic versions of binutils which
> had some confusion regarding how instructions should be encoded for .inst
> which we work around with the __emit_inst() macro. Unfortunately we have
> not consistently used this macro, one of the places where it's missed being
> the macros that manually encode v8.2 crypto instructions. This means that
> kernels built with such toolchains have never supported use of the affected
> instructions correctly.
>
> Since these toolchains are very old (some idle research suggested 2015
> era) it seems more sensible to just refuse to build v8.2 crypto support
> with them, in the unlikely event that someone has a need to use such a
> toolchain to build a kernel which will run on a system with v8.2 crypto
> support they can always fix this properly but it seems more likely that
> we will deprecate support for these toolchains and remove __emit_inst()
> before that happens.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
IIRC this is not about .inst getting the encoding wrong, but about
confusion over the size of the generated opcode, resulting in problems
generating constants involving relative offsets between labels. (The
endian swap is there so that .long can be used on BE to emit the LE
opcodes)
This is not an issue here, so I don't think this change is necessary.
> ---
> arch/arm64/crypto/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
> index 2a965aa0188d..90dd62d46739 100644
> --- a/arch/arm64/crypto/Kconfig
> +++ b/arch/arm64/crypto/Kconfig
> @@ -32,12 +32,14 @@ config CRYPTO_SHA2_ARM64_CE
> config CRYPTO_SHA512_ARM64_CE
> tristate "SHA-384/SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_HASH
> select CRYPTO_SHA512_ARM64
>
> config CRYPTO_SHA3_ARM64
> tristate "SHA3 digest algorithm (ARMv8.2 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_HASH
> select CRYPTO_SHA3
>
> @@ -50,6 +52,7 @@ config CRYPTO_SM3_ARM64_CE
> config CRYPTO_SM4_ARM64_CE
> tristate "SM4 symmetric cipher (ARMv8.2 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_ALGAPI
> select CRYPTO_LIB_SM4
>
> --
> 2.30.2
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
@ 2022-03-03 7:26 ` Ard Biesheuvel
0 siblings, 0 replies; 8+ messages in thread
From: Ard Biesheuvel @ 2022-03-03 7:26 UTC (permalink / raw)
To: Mark Brown, Marc Zyngier
Cc: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon,
Linux Crypto Mailing List, Linux ARM
On Wed, 2 Mar 2022 at 16:54, Mark Brown <broonie@kernel.org> wrote:
>
> We support building the kernel with archaic versions of binutils which
> had some confusion regarding how instructions should be encoded for .inst
> which we work around with the __emit_inst() macro. Unfortunately we have
> not consistently used this macro, one of the places where it's missed being
> the macros that manually encode v8.2 crypto instructions. This means that
> kernels built with such toolchains have never supported use of the affected
> instructions correctly.
>
> Since these toolchains are very old (some idle research suggested 2015
> era) it seems more sensible to just refuse to build v8.2 crypto support
> with them, in the unlikely event that someone has a need to use such a
> toolchain to build a kernel which will run on a system with v8.2 crypto
> support they can always fix this properly but it seems more likely that
> we will deprecate support for these toolchains and remove __emit_inst()
> before that happens.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
IIRC this is not about .inst getting the encoding wrong, but about
confusion over the size of the generated opcode, resulting in problems
generating constants involving relative offsets between labels. (The
endian swap is there so that .long can be used on BE to emit the LE
opcodes)
This is not an issue here, so I don't think this change is necessary.
> ---
> arch/arm64/crypto/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
> index 2a965aa0188d..90dd62d46739 100644
> --- a/arch/arm64/crypto/Kconfig
> +++ b/arch/arm64/crypto/Kconfig
> @@ -32,12 +32,14 @@ config CRYPTO_SHA2_ARM64_CE
> config CRYPTO_SHA512_ARM64_CE
> tristate "SHA-384/SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_HASH
> select CRYPTO_SHA512_ARM64
>
> config CRYPTO_SHA3_ARM64
> tristate "SHA3 digest algorithm (ARMv8.2 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_HASH
> select CRYPTO_SHA3
>
> @@ -50,6 +52,7 @@ config CRYPTO_SM3_ARM64_CE
> config CRYPTO_SM4_ARM64_CE
> tristate "SM4 symmetric cipher (ARMv8.2 Crypto Extensions)"
> depends on KERNEL_MODE_NEON
> + depends on !BROKEN_GAS_INST
> select CRYPTO_ALGAPI
> select CRYPTO_LIB_SM4
>
> --
> 2.30.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
2022-03-03 7:26 ` Ard Biesheuvel
@ 2022-03-03 11:16 ` Marc Zyngier
-1 siblings, 0 replies; 8+ messages in thread
From: Marc Zyngier @ 2022-03-03 11:16 UTC (permalink / raw)
To: Mark Brown, Ard Biesheuvel
Cc: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon,
Linux Crypto Mailing List, Linux ARM
On Thu, 03 Mar 2022 07:26:45 +0000,
Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 2 Mar 2022 at 16:54, Mark Brown <broonie@kernel.org> wrote:
> >
> > We support building the kernel with archaic versions of binutils which
> > had some confusion regarding how instructions should be encoded for .inst
> > which we work around with the __emit_inst() macro. Unfortunately we have
> > not consistently used this macro, one of the places where it's missed being
> > the macros that manually encode v8.2 crypto instructions. This means that
> > kernels built with such toolchains have never supported use of the affected
> > instructions correctly.
> >
> > Since these toolchains are very old (some idle research suggested 2015
> > era) it seems more sensible to just refuse to build v8.2 crypto support
> > with them, in the unlikely event that someone has a need to use such a
> > toolchain to build a kernel which will run on a system with v8.2 crypto
> > support they can always fix this properly but it seems more likely that
> > we will deprecate support for these toolchains and remove __emit_inst()
> > before that happens.
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
>
> IIRC this is not about .inst getting the encoding wrong, but about
> confusion over the size of the generated opcode, resulting in problems
> generating constants involving relative offsets between labels. (The
> endian swap is there so that .long can be used on BE to emit the LE
> opcodes)
>
> This is not an issue here, so I don't think this change is necessary.
Indeed. The only case where the broken GAS .inst has hit us was in
combination with alternatives (see eb7c11ee3c5c for details). The
encoding itself is always correct, and it is only the label generation
that was broken. If we were affected by this, the kernel would simply
fail to build with these toolchains.
If this ever happens (because we'd add some extra alternative
sequences to the crypto code?), we can revisit this. But in the
meantime, I don't see anything warranting this extra dependency.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
@ 2022-03-03 11:16 ` Marc Zyngier
0 siblings, 0 replies; 8+ messages in thread
From: Marc Zyngier @ 2022-03-03 11:16 UTC (permalink / raw)
To: Mark Brown, Ard Biesheuvel
Cc: Herbert Xu, David S . Miller, Catalin Marinas, Will Deacon,
Linux Crypto Mailing List, Linux ARM
On Thu, 03 Mar 2022 07:26:45 +0000,
Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 2 Mar 2022 at 16:54, Mark Brown <broonie@kernel.org> wrote:
> >
> > We support building the kernel with archaic versions of binutils which
> > had some confusion regarding how instructions should be encoded for .inst
> > which we work around with the __emit_inst() macro. Unfortunately we have
> > not consistently used this macro, one of the places where it's missed being
> > the macros that manually encode v8.2 crypto instructions. This means that
> > kernels built with such toolchains have never supported use of the affected
> > instructions correctly.
> >
> > Since these toolchains are very old (some idle research suggested 2015
> > era) it seems more sensible to just refuse to build v8.2 crypto support
> > with them, in the unlikely event that someone has a need to use such a
> > toolchain to build a kernel which will run on a system with v8.2 crypto
> > support they can always fix this properly but it seems more likely that
> > we will deprecate support for these toolchains and remove __emit_inst()
> > before that happens.
> >
> > Signed-off-by: Mark Brown <broonie@kernel.org>
>
> IIRC this is not about .inst getting the encoding wrong, but about
> confusion over the size of the generated opcode, resulting in problems
> generating constants involving relative offsets between labels. (The
> endian swap is there so that .long can be used on BE to emit the LE
> opcodes)
>
> This is not an issue here, so I don't think this change is necessary.
Indeed. The only case where the broken GAS .inst has hit us was in
combination with alternatives (see eb7c11ee3c5c for details). The
encoding itself is always correct, and it is only the label generation
that was broken. If we were affected by this, the kernel would simply
fail to build with these toolchains.
If this ever happens (because we'd add some extra alternative
sequences to the crypto code?), we can revisit this. But in the
meantime, I don't see anything warranting this extra dependency.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
2022-03-03 11:16 ` Marc Zyngier
@ 2022-03-03 12:35 ` Mark Brown
-1 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2022-03-03 12:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: Ard Biesheuvel, Herbert Xu, David S . Miller, Catalin Marinas,
Will Deacon, Linux Crypto Mailing List, Linux ARM
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
On Thu, Mar 03, 2022 at 11:16:28AM +0000, Marc Zyngier wrote:
> Indeed. The only case where the broken GAS .inst has hit us was in
> combination with alternatives (see eb7c11ee3c5c for details). The
> encoding itself is always correct, and it is only the label generation
> that was broken. If we were affected by this, the kernel would simply
> fail to build with these toolchains.
> If this ever happens (because we'd add some extra alternative
> sequences to the crypto code?), we can revisit this. But in the
> meantime, I don't see anything warranting this extra dependency.
Ah, in that case the SVE code should be fine too and there's no issue
with either. I'd understood the issue to be with the actual instruction
encoding.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST
@ 2022-03-03 12:35 ` Mark Brown
0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2022-03-03 12:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: Ard Biesheuvel, Herbert Xu, David S . Miller, Catalin Marinas,
Will Deacon, Linux Crypto Mailing List, Linux ARM
[-- Attachment #1.1: Type: text/plain, Size: 736 bytes --]
On Thu, Mar 03, 2022 at 11:16:28AM +0000, Marc Zyngier wrote:
> Indeed. The only case where the broken GAS .inst has hit us was in
> combination with alternatives (see eb7c11ee3c5c for details). The
> encoding itself is always correct, and it is only the label generation
> that was broken. If we were affected by this, the kernel would simply
> fail to build with these toolchains.
> If this ever happens (because we'd add some extra alternative
> sequences to the crypto code?), we can revisit this. But in the
> meantime, I don't see anything warranting this extra dependency.
Ah, in that case the SVE code should be fine too and there's no issue
with either. I'd understood the issue to be with the actual instruction
encoding.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-03-03 12:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-03-02 16:54 [PATCH] arm64: crypto: Don't allow v8.2 extensions to be used with BROKEN_GAS_INST Mark Brown
2022-03-02 16:54 ` Mark Brown
2022-03-03 7:26 ` Ard Biesheuvel
2022-03-03 7:26 ` Ard Biesheuvel
2022-03-03 11:16 ` Marc Zyngier
2022-03-03 11:16 ` Marc Zyngier
2022-03-03 12:35 ` Mark Brown
2022-03-03 12:35 ` Mark Brown
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.