[PATCH 1/2] arm64: lib: Use .arch_extension

[PATCH 1/2] arm64: lib: Use .arch_extension

[Mark Brown]

Currently when implementing optimised assembler routines using
architecture extensions we override the base architecture along with
enabling the new extensions, causing problems for in kernel BTI support
which needs to raise the base architecture level for assembler files in
order to generate BTI landing pads.  We did this due to a lack of
support for the .arch_extension gas feature in older versions of the
clang built in assembler but since current versions of clang now have
support for .arch_extension we can use that.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/lib/crc32.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index 243e107e9896..7420dea6afc1 100644
--- a/arch/arm64/lib/crc32.S
+++ b/arch/arm64/lib/crc32.S
@@ -9,7 +9,7 @@
 #include <asm/alternative.h>
 #include <asm/assembler.h>
 
-	.cpu		generic+crc
+	.arch_extension crc
 
 	.macro		__crc32, c
 	cmp		x2, #16
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] arm64: crypto: Use .arch_extension

[Mark Brown]

Currently when implementing optimised assembler routines using
architecture extensions we override the base architecture along with
enabling the new extensions, causing problems for in kernel BTI support
which needs to raise the base architecture level for assembler files in
order to generate BTI landing pads.  We did this due to a lack of
support for the .arch_extension gas feature in older versions of the
clang built in assembler but since current versions of clang now have
support for .arch_extension we can use that.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/crypto/aes-ce-ccm-core.S   | 2 +-
 arch/arm64/crypto/aes-ce-core.S       | 2 +-
 arch/arm64/crypto/aes-ce.S            | 2 +-
 arch/arm64/crypto/crct10dif-ce-core.S | 2 +-
 arch/arm64/crypto/ghash-ce-core.S     | 2 +-
 arch/arm64/crypto/sha1-ce-core.S      | 2 +-
 arch/arm64/crypto/sha2-ce-core.S      | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index 99a028e298ed..90fde12f8253 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -9,7 +9,7 @@
 #include <asm/assembler.h>
 
 	.text
-	.arch	armv8-a+crypto
+	.arch_extension crypto
 
 	/*
 	 * void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
diff --git a/arch/arm64/crypto/aes-ce-core.S b/arch/arm64/crypto/aes-ce-core.S
index e52e13eb8fdb..4dbc0052ffbe 100644
--- a/arch/arm64/crypto/aes-ce-core.S
+++ b/arch/arm64/crypto/aes-ce-core.S
@@ -6,7 +6,7 @@
 #include <linux/linkage.h>
 #include <asm/assembler.h>
 
-	.arch		armv8-a+crypto
+	.arch_extension crypto
 
 SYM_FUNC_START(__aes_ce_encrypt)
 	sub		w3, w3, #2
diff --git a/arch/arm64/crypto/aes-ce.S b/arch/arm64/crypto/aes-ce.S
index 1dc5bbbfeed2..d57516308cf1 100644
--- a/arch/arm64/crypto/aes-ce.S
+++ b/arch/arm64/crypto/aes-ce.S
@@ -12,7 +12,7 @@
 #define AES_FUNC_START(func)		SYM_FUNC_START(ce_ ## func)
 #define AES_FUNC_END(func)		SYM_FUNC_END(ce_ ## func)
 
-	.arch		armv8-a+crypto
+	.arch_extension crypto
 
 	xtsmask		.req	v16
 	cbciv		.req	v16
diff --git a/arch/arm64/crypto/crct10dif-ce-core.S b/arch/arm64/crypto/crct10dif-ce-core.S
index 5a95c2628fbf..c6b8b387f3bd 100644
--- a/arch/arm64/crypto/crct10dif-ce-core.S
+++ b/arch/arm64/crypto/crct10dif-ce-core.S
@@ -66,7 +66,7 @@
 #include <asm/assembler.h>
 
 	.text
-	.cpu		generic+crypto
+	.arch_extension crypto
 
 	init_crc	.req	w19
 	buf		.req	x20
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index 6b958dcdf136..65ed5690735a 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -57,7 +57,7 @@
 	HH34		.req	v19
 
 	.text
-	.arch		armv8-a+crypto
+	.arch_extension crypto
 
 	.macro		__pmull_p64, rd, rn, rm
 	pmull		\rd\().1q, \rn\().1d, \rm\().1d
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 92d0d2753e81..8cfd30c5f605 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -9,7 +9,7 @@
 #include <asm/assembler.h>
 
 	.text
-	.arch		armv8-a+crypto
+	.arch_extension crypto
 
 	k0		.req	v0
 	k1		.req	v1
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 3f9d0f326987..a7ea4fc8d570 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -9,7 +9,7 @@
 #include <asm/assembler.h>
 
 	.text
-	.arch		armv8-a+crypto
+	.arch_extension crypto
 
 	dga		.req	q20
 	dgav		.req	v20
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] arm64: crypto: Use .arch_extension

[Catalin Marinas]

On Mon, Mar 23, 2020 at 07:18:07PM +0000, Mark Brown wrote:
> Currently when implementing optimised assembler routines using
> architecture extensions we override the base architecture along with
> enabling the new extensions, causing problems for in kernel BTI support
> which needs to raise the base architecture level for assembler files in
> order to generate BTI landing pads.  We did this due to a lack of
> support for the .arch_extension gas feature in older versions of the
> clang built in assembler but since current versions of clang now have
> support for .arch_extension we can use that.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

It make sense (I got burnt by this with the MTE patches).

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Catalin Marinas]

On Mon, Mar 23, 2020 at 07:18:06PM +0000, Mark Brown wrote:
> Currently when implementing optimised assembler routines using
> architecture extensions we override the base architecture along with
> enabling the new extensions, causing problems for in kernel BTI support
> which needs to raise the base architecture level for assembler files in
> order to generate BTI landing pads.  We did this due to a lack of
> support for the .arch_extension gas feature in older versions of the
> clang built in assembler but since current versions of clang now have
> support for .arch_extension we can use that.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

I'll queue this through the arm64 tree. Thanks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Ard Biesheuvel]

On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote:
>
> Currently when implementing optimised assembler routines using
> architecture extensions we override the base architecture along with
> enabling the new extensions, causing problems for in kernel BTI support
> which needs to raise the base architecture level for assembler files in
> order to generate BTI landing pads.  We did this due to a lack of
> support for the .arch_extension gas feature in older versions of the
> clang built in assembler but since current versions of clang now have
> support for .arch_extension we can use that.

This is not 100% accurate. Support for .arch_extension was added to
GAS/aarch64 much later, so we should at least double check that it
works on the oldest binutils that we do support.

>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/lib/crc32.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
> index 243e107e9896..7420dea6afc1 100644
> --- a/arch/arm64/lib/crc32.S
> +++ b/arch/arm64/lib/crc32.S
> @@ -9,7 +9,7 @@
>  #include <asm/alternative.h>
>  #include <asm/assembler.h>
>
> -       .cpu            generic+crc
> +       .arch_extension crc
>
>         .macro          __crc32, c
>         cmp             x2, #16
> --
> 2.20.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]

On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote:
> On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote:

> > order to generate BTI landing pads.  We did this due to a lack of
> > support for the .arch_extension gas feature in older versions of the
> > clang built in assembler but since current versions of clang now have
> > support for .arch_extension we can use that.

> This is not 100% accurate. Support for .arch_extension was added to
> GAS/aarch64 much later, so we should at least double check that it
> works on the oldest binutils that we do support.

Ah, OK - the information I figured out from history was misleading
sorry.  

We've already got quite a lot of usages of .arch_extension in the kernel
for arm and a couple for arm64 (one in TF and another for LSE).  It
looks like the feature was added in binutils 2.26 which is newer than
the current advertised minimum binutils version of 2.21 but dates from
2016 (the code was added in 2014 and looks like it might've appeared in
downstream releases earlier) so is pretty old in arm64 terms.  If that's
not OK I've got an open coded version for BTI that does this with macros
but it's obviously not as nice.

I do wish the binutils docs included information on when features were
added, it'd make life easier :/

[-- 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

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Ard Biesheuvel]

On Tue, 24 Mar 2020 at 19:58, Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote:
> > On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote:
>
> > > order to generate BTI landing pads.  We did this due to a lack of
> > > support for the .arch_extension gas feature in older versions of the
> > > clang built in assembler but since current versions of clang now have
> > > support for .arch_extension we can use that.
>
> > This is not 100% accurate. Support for .arch_extension was added to
> > GAS/aarch64 much later, so we should at least double check that it
> > works on the oldest binutils that we do support.
>
> Ah, OK - the information I figured out from history was misleading
> sorry.
>
> We've already got quite a lot of usages of .arch_extension in the kernel
> for arm and a couple for arm64 (one in TF and another for LSE).

ARM had support for this way before it was added to AArch64 as well.
In the LSE case, it doesn't matter since LSE itself was not
implemented by the assembler before that. For other things, we should
really avoid .arch_extension as long as we still support binutils <
2.26

>  It
> looks like the feature was added in binutils 2.26 which is newer than
> the current advertised minimum binutils version of 2.21 but dates from
> 2016 (the code was added in 2014 and looks like it might've appeared in
> downstream releases earlier) so is pretty old in arm64 terms.  If that's
> not OK I've got an open coded version for BTI that does this with macros
> but it's obviously not as nice.
>
> I do wish the binutils docs included information on when features were
> added, it'd make life easier :/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Catalin Marinas]

On Tue, Mar 24, 2020 at 11:17:05PM +0100, Ard Biesheuvel wrote:
> On Tue, 24 Mar 2020 at 19:58, Mark Brown <broonie@kernel.org> wrote:
> >
> > On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote:
> > > On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote:
> >
> > > > order to generate BTI landing pads.  We did this due to a lack of
> > > > support for the .arch_extension gas feature in older versions of the
> > > > clang built in assembler but since current versions of clang now have
> > > > support for .arch_extension we can use that.
> >
> > > This is not 100% accurate. Support for .arch_extension was added to
> > > GAS/aarch64 much later, so we should at least double check that it
> > > works on the oldest binutils that we do support.
> >
> > Ah, OK - the information I figured out from history was misleading
> > sorry.
> >
> > We've already got quite a lot of usages of .arch_extension in the kernel
> > for arm and a couple for arm64 (one in TF and another for LSE).
> 
> ARM had support for this way before it was added to AArch64 as well.
> In the LSE case, it doesn't matter since LSE itself was not
> implemented by the assembler before that. For other things, we should
> really avoid .arch_extension as long as we still support binutils <
> 2.26

Good point. So we can add .arch_extension for new features which are
already dependent on newer gas options.

I'll drop this patch for now but we should try to find a solution
because of the overriding effect of .arch. In self-contained .S files
(like crypto) that's not an issue but once we start adding more
architecture feature in a single file, things will get more complicated.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: lib: Use .arch_extension

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]

On Wed, Mar 25, 2020 at 11:05:04AM +0000, Catalin Marinas wrote:

> I'll drop this patch for now but we should try to find a solution
> because of the overriding effect of .arch. In self-contained .S files
> (like crypto) that's not an issue but once we start adding more
> architecture feature in a single file, things will get more complicated.

It's fine I think, you can open code .arch_extension in the assembler.

[-- 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