[PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

This series is a followup to the patch that was recently merged by Catalin that
allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
discover whether the current CPU has any of those capabilities.

Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
was recently added to the kernel and glibc (2.18). It extends the feature bit
space to 64 bits (on 32-bit architectures)

Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
mode for 64-bit architectures.

Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode

Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
so there should be agreement about the meaning of feature bits, even if the ARM
kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R)

Patch #5 advertises the CRC and Crypto Extensions to 32-bit ELF binaries running
under an arm64 kernel.

v2 changes:
- omitted 2 arm64 specific patches that have already been merged by Catalin
- move ARM feature bits to HWCAP2

Ard Biesheuvel (5):
  ARM: add support for AT_HWCAP2 ELF auxv entry
  binfmt_elf: add ELF_HWCAP2 to compat auxv entries
  arm64: add AT_HWCAP2 support for 32-bit compat
  ARM: introduce HWCAP2 feature bits for ARMv8 Crypto Extensions
  arm64: advertise ARMv8 extensions to 32-bit compat ELF binaries

 arch/arm/include/asm/hwcap.h      |  3 ++-
 arch/arm/include/uapi/asm/hwcap.h |  9 +++++++++
 arch/arm/kernel/setup.c           | 16 ++++++++++++++++
 arch/arm64/include/asm/hwcap.h    |  9 ++++++++-
 arch/arm64/kernel/setup.c         | 33 +++++++++++++++++++++++++++++++++
 fs/compat_binfmt_elf.c            |  5 +++++
 6 files changed, 73 insertions(+), 2 deletions(-)

-- 
1.8.3.2

[PATCH v2 1/5] ARM: add support for AT_HWCAP2 ELF auxv entry

[Ard Biesheuvel]

This enables AT_HWCAP2 for ARM. The generic support for this
new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
Add HWCAP2 aux entry)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/include/asm/hwcap.h      |  3 ++-
 arch/arm/include/uapi/asm/hwcap.h |  4 ++++
 arch/arm/kernel/setup.c           | 11 +++++++++++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hwcap.h b/arch/arm/include/asm/hwcap.h
index 6ff56ec..6e183fd 100644
--- a/arch/arm/include/asm/hwcap.h
+++ b/arch/arm/include/asm/hwcap.h
@@ -9,6 +9,7 @@
  * instruction set this cpu supports.
  */
 #define ELF_HWCAP	(elf_hwcap)
-extern unsigned int elf_hwcap;
+#define ELF_HWCAP2	(elf_hwcap2)
+extern unsigned int elf_hwcap, elf_hwcap2;
 #endif
 #endif
diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
index 7dcc10d..87768b5 100644
--- a/arch/arm/include/uapi/asm/hwcap.h
+++ b/arch/arm/include/uapi/asm/hwcap.h
@@ -28,4 +28,8 @@
 #define HWCAP_LPAE	(1 << 20)
 #define HWCAP_EVTSTRM	(1 << 21)
 
+/*
+ * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
+ */
+
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 987a7f5..ce3049c 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -100,6 +100,9 @@ EXPORT_SYMBOL(system_serial_high);
 unsigned int elf_hwcap __read_mostly;
 EXPORT_SYMBOL(elf_hwcap);
 
+unsigned int elf_hwcap2 __read_mostly;
+EXPORT_SYMBOL(elf_hwcap2);
+
 
 #ifdef MULTI_CPU
 struct processor processor __read_mostly;
@@ -992,6 +995,10 @@ static const char *hwcap_str[] = {
 	NULL
 };
 
+static const char *hwcap2_str[] = {
+	NULL
+};
+
 static int c_show(struct seq_file *m, void *v)
 {
 	int i, j;
@@ -1015,6 +1022,10 @@ static int c_show(struct seq_file *m, void *v)
 			if (elf_hwcap & (1 << j))
 				seq_printf(m, "%s ", hwcap_str[j]);
 
+		for (j = 0; hwcap2_str[j]; j++)
+			if (elf_hwcap2 & (1 << j))
+				seq_printf(m, "%s ", hwcap2_str[j]);
+
 		seq_printf(m, "\nCPU implementer\t: 0x%02x\n", cpuid >> 24);
 		seq_printf(m, "CPU architecture: %s\n",
 			   proc_arch[cpu_architecture()]);
-- 
1.8.3.2

[PATCH v2 2/5] binfmt_elf: add ELF_HWCAP2 to compat auxv entries

[Ard Biesheuvel]

Add ELF_HWCAP2 to the set of auxv entries that is passed to
a 32-bit ELF program running in 32-bit compat mode under a
64-bit kernel.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 fs/compat_binfmt_elf.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/compat_binfmt_elf.c b/fs/compat_binfmt_elf.c
index a81147e..4d24d17 100644
--- a/fs/compat_binfmt_elf.c
+++ b/fs/compat_binfmt_elf.c
@@ -88,6 +88,11 @@ static void cputime_to_compat_timeval(const cputime_t cputime,
 #define	ELF_HWCAP		COMPAT_ELF_HWCAP
 #endif
 
+#ifdef	COMPAT_ELF_HWCAP2
+#undef	ELF_HWCAP2
+#define	ELF_HWCAP2		COMPAT_ELF_HWCAP2
+#endif
+
 #ifdef	COMPAT_ARCH_DLINFO
 #undef	ARCH_DLINFO
 #define	ARCH_DLINFO		COMPAT_ARCH_DLINFO
-- 
1.8.3.2

[PATCH v2 3/5] arm64: add AT_HWCAP2 support for 32-bit compat

[Ard Biesheuvel]

Add support for the ELF auxv entry AT_HWCAP2 when running 32-bit
ELF binaries in compat mode.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/include/asm/hwcap.h | 3 ++-
 arch/arm64/kernel/setup.c      | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 6cddbb0..9a4cbd6 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -41,7 +41,8 @@
 
 #ifdef CONFIG_COMPAT
 #define COMPAT_ELF_HWCAP	(compat_elf_hwcap)
-extern unsigned int compat_elf_hwcap;
+#define COMPAT_ELF_HWCAP2	(compat_elf_hwcap2)
+extern unsigned int compat_elf_hwcap, compat_elf_hwcap2;
 #endif
 
 extern unsigned long elf_hwcap;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bb33fff..15f3bd2 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -69,6 +69,7 @@ EXPORT_SYMBOL_GPL(elf_hwcap);
 				 COMPAT_HWCAP_VFPv3|COMPAT_HWCAP_VFPv4|\
 				 COMPAT_HWCAP_NEON|COMPAT_HWCAP_IDIV)
 unsigned int compat_elf_hwcap __read_mostly = COMPAT_ELF_HWCAP_DEFAULT;
+unsigned int compat_elf_hwcap2 __read_mostly;
 #endif
 
 static const char *cpu_name;
-- 
1.8.3.2

[PATCH v2 4/5] ARM: introduce HWCAP2 feature bits for ARMv8 Crypto Extensions

[Ard Biesheuvel]

This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC
extensions introduced in ARMv8.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/include/uapi/asm/hwcap.h | 5 +++++
 arch/arm/kernel/setup.c           | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/include/uapi/asm/hwcap.h b/arch/arm/include/uapi/asm/hwcap.h
index 87768b5..20d12f2 100644
--- a/arch/arm/include/uapi/asm/hwcap.h
+++ b/arch/arm/include/uapi/asm/hwcap.h
@@ -31,5 +31,10 @@
 /*
  * HWCAP2 flags - for elf_hwcap2 (in kernel) and AT_HWCAP2
  */
+#define HWCAP2_AES	(1 << 0)
+#define HWCAP2_PMULL	(1 << 1)
+#define HWCAP2_SHA1	(1 << 2)
+#define HWCAP2_SHA2	(1 << 3)
+#define HWCAP2_CRC32	(1 << 4)
 
 #endif /* _UAPI__ASMARM_HWCAP_H */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index ce3049c..ac3a7f2 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -996,6 +996,11 @@ static const char *hwcap_str[] = {
 };
 
 static const char *hwcap2_str[] = {
+	"aes",
+	"pmull",
+	"sha1",
+	"sha2",
+	"crc32",
 	NULL
 };
 
-- 
1.8.3.2

[PATCH v2 5/5] arm64: advertise ARMv8 extensions to 32-bit compat ELF binaries

[Ard Biesheuvel]

This adds support for advertising the presence of ARMv8 Crypto
Extensions in the Aarch32 execution state to 32-bit ELF binaries
running in 32-bit compat mode under the arm64 kernel.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/include/asm/hwcap.h |  6 ++++++
 arch/arm64/kernel/setup.c      | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 9a4cbd6..024c461 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -32,6 +32,12 @@
 #define COMPAT_HWCAP_IDIV	(COMPAT_HWCAP_IDIVA|COMPAT_HWCAP_IDIVT)
 #define COMPAT_HWCAP_EVTSTRM	(1 << 21)
 
+#define COMPAT_HWCAP2_AES	(1 << 0)
+#define COMPAT_HWCAP2_PMULL	(1 << 1)
+#define COMPAT_HWCAP2_SHA1	(1 << 2)
+#define COMPAT_HWCAP2_SHA2	(1 << 3)
+#define COMPAT_HWCAP2_CRC32	(1 << 4)
+
 #ifndef __ASSEMBLY__
 /*
  * This yields a mask that user programs can use to figure out what
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 15f3bd2..c36cab8 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -174,6 +174,38 @@ static void __init setup_processor(void)
 	block = (features >> 16) & 0xf;
 	if (block && !(block & 0x8))
 		elf_hwcap |= HWCAP_CRC32;
+
+#ifdef CONFIG_COMPAT
+	/*
+	 * ID_ISAR5_EL1 carries similar information as above, but pertaining to
+	 * the Aarch32 32-bit execution state.
+	 */
+	features = read_cpuid(ID_ISAR5_EL1);
+	block = (features >> 4) & 0xf;
+	if (!(block & 0x8)) {
+		switch (block) {
+		default:
+		case 2:
+			compat_elf_hwcap2 |= COMPAT_HWCAP2_PMULL;
+		case 1:
+			compat_elf_hwcap2 |= COMPAT_HWCAP2_AES;
+		case 0:
+			break;
+		}
+	}
+
+	block = (features >> 8) & 0xf;
+	if (block && !(block & 0x8))
+		compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA1;
+
+	block = (features >> 12) & 0xf;
+	if (block && !(block & 0x8))
+		compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA2;
+
+	block = (features >> 16) & 0xf;
+	if (block && !(block & 0x8))
+		compat_elf_hwcap2 |= COMPAT_HWCAP2_CRC32;
+#endif
 }
 
 static void __init setup_machine_fdt(phys_addr_t dt_phys)
-- 
1.8.3.2

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

@Russell, Nico,

Care to share your opinion on this alternative approach to allocating
hwcap feature bits for the ARMv8 Crypto Extensions for 32-bit ARM?

Regards,
Ard.


On 23 December 2013 15:06, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This series is a followup to the patch that was recently merged by Catalin that
> allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
> discover whether the current CPU has any of those capabilities.
>
> Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
> was recently added to the kernel and glibc (2.18). It extends the feature bit
> space to 64 bits (on 32-bit architectures)
>
> Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
> mode for 64-bit architectures.
>
> Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
>
> Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
> because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
> so there should be agreement about the meaning of feature bits, even if the ARM
> kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R)
>
> Patch #5 advertises the CRC and Crypto Extensions to 32-bit ELF binaries running
> under an arm64 kernel.
>
> v2 changes:
> - omitted 2 arm64 specific patches that have already been merged by Catalin
> - move ARM feature bits to HWCAP2
>
> Ard Biesheuvel (5):
>   ARM: add support for AT_HWCAP2 ELF auxv entry
>   binfmt_elf: add ELF_HWCAP2 to compat auxv entries
>   arm64: add AT_HWCAP2 support for 32-bit compat
>   ARM: introduce HWCAP2 feature bits for ARMv8 Crypto Extensions
>   arm64: advertise ARMv8 extensions to 32-bit compat ELF binaries
>
>  arch/arm/include/asm/hwcap.h      |  3 ++-
>  arch/arm/include/uapi/asm/hwcap.h |  9 +++++++++
>  arch/arm/kernel/setup.c           | 16 ++++++++++++++++
>  arch/arm64/include/asm/hwcap.h    |  9 ++++++++-
>  arch/arm64/kernel/setup.c         | 33 +++++++++++++++++++++++++++++++++
>  fs/compat_binfmt_elf.c            |  5 +++++
>  6 files changed, 73 insertions(+), 2 deletions(-)
>
> --
> 1.8.3.2
>

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Catalin Marinas]

On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
> This series is a followup to the patch that was recently merged by Catalin that
> allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
> discover whether the current CPU has any of those capabilities.
> 
> Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
> was recently added to the kernel and glibc (2.18). It extends the feature bit
> space to 64 bits (on 32-bit architectures)
> 
> Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
> mode for 64-bit architectures.
> 
> Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
> 
> Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
> because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
> so there should be agreement about the meaning of feature bits, even if the ARM
> kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).

It looks a bit strange to start filling HWCAP2 before HWCAP is full but
I guess we want to preserve some future extensions in HWCAP for older
glibc.

-- 
Catalin

Re: [PATCH v2 1/5] ARM: add support for AT_HWCAP2 ELF auxv entry

[Catalin Marinas]

On Mon, Dec 23, 2013 at 02:06:28PM +0000, Ard Biesheuvel wrote:
> This enables AT_HWCAP2 for ARM. The generic support for this
> new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
> Add HWCAP2 aux entry)
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

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

Re: [PATCH v2 2/5] binfmt_elf: add ELF_HWCAP2 to compat auxv entries

[Catalin Marinas]

On Mon, Dec 23, 2013 at 02:06:29PM +0000, Ard Biesheuvel wrote:
> Add ELF_HWCAP2 to the set of auxv entries that is passed to
> a 32-bit ELF program running in 32-bit compat mode under a
> 64-bit kernel.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

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

Re: [PATCH v2 4/5] ARM: introduce HWCAP2 feature bits for ARMv8 Crypto Extensions

[Catalin Marinas]

On Mon, Dec 23, 2013 at 02:06:31PM +0000, Ard Biesheuvel wrote:
> This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC
> extensions introduced in ARMv8.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

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

Re: [PATCH v2 5/5] arm64: advertise ARMv8 extensions to 32-bit compat ELF binaries

[Catalin Marinas]

On Mon, Dec 23, 2013 at 02:06:32PM +0000, Ard Biesheuvel wrote:
> This adds support for advertising the presence of ARMv8 Crypto
> Extensions in the Aarch32 execution state to 32-bit ELF binaries
> running in 32-bit compat mode under the arm64 kernel.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

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

(for both arm64 patches in case they go in via a different route;
otherwise I'll take the arm64 patches if Russell is ok with merging the
arm ones)

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Nicolas Pitre]

On Mon, 20 Jan 2014, Catalin Marinas wrote:

> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
> > This series is a followup to the patch that was recently merged by Catalin that
> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
> > discover whether the current CPU has any of those capabilities.
> > 
> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
> > was recently added to the kernel and glibc (2.18). It extends the feature bit
> > space to 64 bits (on 32-bit architectures)
> > 
> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
> > mode for 64-bit architectures.
> > 
> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
> > 
> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
> > so there should be agreement about the meaning of feature bits, even if the ARM
> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
> 
> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
> I guess we want to preserve some future extensions in HWCAP for older
> glibc.

How could older glibc possibly care about future extensions?


Nicolas

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Catalin Marinas wrote:
>
>> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
>> > This series is a followup to the patch that was recently merged by Catalin that
>> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
>> > discover whether the current CPU has any of those capabilities.
>> >
>> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
>> > was recently added to the kernel and glibc (2.18). It extends the feature bit
>> > space to 64 bits (on 32-bit architectures)
>> >
>> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
>> > mode for 64-bit architectures.
>> >
>> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
>> >
>> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
>> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
>> > so there should be agreement about the meaning of feature bits, even if the ARM
>> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
>>
>> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
>> I guess we want to preserve some future extensions in HWCAP for older
>> glibc.
>
> How could older glibc possibly care about future extensions?
>

Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
whole value, not just the bits whose meaning was known to glibc at the
time.
So if desired, a program can interpret AT_HWCAP itself.

AT_HWCAP2 is completely new, so you won't be able to retrieve it using
getauxval() on an older libc.

-- 
Ard.

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Nicolas Pitre]

On Mon, 20 Jan 2014, Ard Biesheuvel wrote:

> On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Catalin Marinas wrote:
> >
> >> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
> >> > This series is a followup to the patch that was recently merged by Catalin that
> >> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
> >> > discover whether the current CPU has any of those capabilities.
> >> >
> >> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
> >> > was recently added to the kernel and glibc (2.18). It extends the feature bit
> >> > space to 64 bits (on 32-bit architectures)
> >> >
> >> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
> >> > mode for 64-bit architectures.
> >> >
> >> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
> >> >
> >> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
> >> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
> >> > so there should be agreement about the meaning of feature bits, even if the ARM
> >> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
> >>
> >> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
> >> I guess we want to preserve some future extensions in HWCAP for older
> >> glibc.
> >
> > How could older glibc possibly care about future extensions?
> >
> 
> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> whole value, not just the bits whose meaning was known to glibc at the
> time.
> So if desired, a program can interpret AT_HWCAP itself.
> 
> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> getauxval() on an older libc.

I agree.  And I don't dispute the bit placement choice either.

Still, an old glibc calling getauxval(AT_HWCAP) should already be 
prepared to receive and rightfully ignore those bits it didn't know the 
meaning of at the time.  So "preserving some future extensions in HWCAP 
for older glibc" as a justification makes little sense to me... unless 
I'm missing something?

Even if applications interpret those bits themselves, supposing they 
still need to be linked against an old glibc, then why would 
yet-to-be-defined future extensions be more important to be signaled 
using the lower 32 bits than the extensions you propose?  That is what I 
don't get.


Nicolas

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>
>> On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Mon, 20 Jan 2014, Catalin Marinas wrote:
>> >
>> >> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
>> >> > This series is a followup to the patch that was recently merged by Catalin that
>> >> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
>> >> > discover whether the current CPU has any of those capabilities.
>> >> >
>> >> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
>> >> > was recently added to the kernel and glibc (2.18). It extends the feature bit
>> >> > space to 64 bits (on 32-bit architectures)
>> >> >
>> >> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
>> >> > mode for 64-bit architectures.
>> >> >
>> >> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
>> >> >
>> >> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
>> >> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
>> >> > so there should be agreement about the meaning of feature bits, even if the ARM
>> >> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
>> >>
>> >> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
>> >> I guess we want to preserve some future extensions in HWCAP for older
>> >> glibc.
>> >
>> > How could older glibc possibly care about future extensions?
>> >
>>
>> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
>> whole value, not just the bits whose meaning was known to glibc at the
>> time.
>> So if desired, a program can interpret AT_HWCAP itself.
>>
>> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
>> getauxval() on an older libc.
>
> I agree.  And I don't dispute the bit placement choice either.
>
> Still, an old glibc calling getauxval(AT_HWCAP) should already be
> prepared to receive and rightfully ignore those bits it didn't know the
> meaning of at the time.  So "preserving some future extensions in HWCAP
> for older glibc" as a justification makes little sense to me... unless
> I'm missing something?
>
> Even if applications interpret those bits themselves, supposing they
> still need to be linked against an old glibc, then why would
> yet-to-be-defined future extensions be more important to be signaled
> using the lower 32 bits than the extensions you propose?  That is what I
> don't get.
>

In the general case, you are quite right.

In this particular case, the extensions for which I am adding the
feature bits are not supported on any hardware currently known or
supported by the ARM port. At this time, the only known CPUs
supporting these extensions are ARMv8 CPUs executing in 32-bit
compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
execution state using previously unallocated opcodes)

So the only reason (currently) for adding these feature bits to the
ARM port is to align with the ARMv8 32-bit compat mode so that a
32-bit userland requires no knowledge about whether its 32-bit
execution environment is hosted by an ARM or an arm64 kernel. In the
future, ARMv8 32-bit only CPUs may well turn up that support these
extensions as well.

-- 
Ard.

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Nicolas Pitre]

On Mon, 20 Jan 2014, Ard Biesheuvel wrote:

> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> >> whole value, not just the bits whose meaning was known to glibc at the
> >> time.
> >> So if desired, a program can interpret AT_HWCAP itself.
> >>
> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> >> getauxval() on an older libc.
> >
> > I agree.  And I don't dispute the bit placement choice either.
> >
> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
> > prepared to receive and rightfully ignore those bits it didn't know the
> > meaning of at the time.  So "preserving some future extensions in HWCAP
> > for older glibc" as a justification makes little sense to me... unless
> > I'm missing something?
> >
> > Even if applications interpret those bits themselves, supposing they
> > still need to be linked against an old glibc, then why would
> > yet-to-be-defined future extensions be more important to be signaled
> > using the lower 32 bits than the extensions you propose?  That is what I
> > don't get.
> >
> 
> In the general case, you are quite right.
> 
> In this particular case, the extensions for which I am adding the
> feature bits are not supported on any hardware currently known or
> supported by the ARM port. At this time, the only known CPUs
> supporting these extensions are ARMv8 CPUs executing in 32-bit
> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
> execution state using previously unallocated opcodes)

So?

> So the only reason (currently) for adding these feature bits to the
> ARM port is to align with the ARMv8 32-bit compat mode so that a
> 32-bit userland requires no knowledge about whether its 32-bit
> execution environment is hosted by an ARM or an arm64 kernel. In the
> future, ARMv8 32-bit only CPUs may well turn up that support these
> extensions as well.

I agree with all you've said so far.  But that doesn't answer my 
question.

And my unanswered question isn't that important either.


Nicolas

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

On 20 January 2014 19:55, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>
>> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
>> >> whole value, not just the bits whose meaning was known to glibc at the
>> >> time.
>> >> So if desired, a program can interpret AT_HWCAP itself.
>> >>
>> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
>> >> getauxval() on an older libc.
>> >
>> > I agree.  And I don't dispute the bit placement choice either.
>> >
>> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
>> > prepared to receive and rightfully ignore those bits it didn't know the
>> > meaning of at the time.  So "preserving some future extensions in HWCAP
>> > for older glibc" as a justification makes little sense to me... unless
>> > I'm missing something?
>> >
>> > Even if applications interpret those bits themselves, supposing they
>> > still need to be linked against an old glibc, then why would
>> > yet-to-be-defined future extensions be more important to be signaled
>> > using the lower 32 bits than the extensions you propose?  That is what I
>> > don't get.
>> >
>>
>> In the general case, you are quite right.
>>
>> In this particular case, the extensions for which I am adding the
>> feature bits are not supported on any hardware currently known or
>> supported by the ARM port. At this time, the only known CPUs
>> supporting these extensions are ARMv8 CPUs executing in 32-bit
>> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
>> execution state using previously unallocated opcodes)
>
> So?
>
>> So the only reason (currently) for adding these feature bits to the
>> ARM port is to align with the ARMv8 32-bit compat mode so that a
>> 32-bit userland requires no knowledge about whether its 32-bit
>> execution environment is hosted by an ARM or an arm64 kernel. In the
>> future, ARMv8 32-bit only CPUs may well turn up that support these
>> extensions as well.
>
> I agree with all you've said so far.  But that doesn't answer my
> question.
>
> And my unanswered question isn't that important either.
>

Quoting Russell:

On 18 December 2013 12:42, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> The point is that they'll never appear on an ARMv7 implementation because
> they're not part of the ARMv7 architecture.  I see no point in needlessly
> polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> no point in polluting ARM64 with ARM32 stuff.
>
> So, frankly, find a different way to this.  We don't need to needlessly
> waste HWCAP bits on ARM32.

So my idea was to use HWCAP2 bits instead ...

-- 
Ard.

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Nicolas Pitre]

On Mon, 20 Jan 2014, Ard Biesheuvel wrote:

> On 20 January 2014 19:55, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >
> >> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> >> >> whole value, not just the bits whose meaning was known to glibc at the
> >> >> time.
> >> >> So if desired, a program can interpret AT_HWCAP itself.
> >> >>
> >> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> >> >> getauxval() on an older libc.
> >> >
> >> > I agree.  And I don't dispute the bit placement choice either.
> >> >
> >> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
> >> > prepared to receive and rightfully ignore those bits it didn't know the
> >> > meaning of at the time.  So "preserving some future extensions in HWCAP
> >> > for older glibc" as a justification makes little sense to me... unless
> >> > I'm missing something?
> >> >
> >> > Even if applications interpret those bits themselves, supposing they
> >> > still need to be linked against an old glibc, then why would
> >> > yet-to-be-defined future extensions be more important to be signaled
> >> > using the lower 32 bits than the extensions you propose?  That is what I
> >> > don't get.
> >> >
> >>
> >> In the general case, you are quite right.
> >>
> >> In this particular case, the extensions for which I am adding the
> >> feature bits are not supported on any hardware currently known or
> >> supported by the ARM port. At this time, the only known CPUs
> >> supporting these extensions are ARMv8 CPUs executing in 32-bit
> >> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
> >> execution state using previously unallocated opcodes)
> >
> > So?
> >
> >> So the only reason (currently) for adding these feature bits to the
> >> ARM port is to align with the ARMv8 32-bit compat mode so that a
> >> 32-bit userland requires no knowledge about whether its 32-bit
> >> execution environment is hosted by an ARM or an arm64 kernel. In the
> >> future, ARMv8 32-bit only CPUs may well turn up that support these
> >> extensions as well.
> >
> > I agree with all you've said so far.  But that doesn't answer my
> > question.
> >
> > And my unanswered question isn't that important either.
> >
> 
> Quoting Russell:
> 
> On 18 December 2013 12:42, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > The point is that they'll never appear on an ARMv7 implementation because
> > they're not part of the ARMv7 architecture.  I see no point in needlessly
> > polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> > no point in polluting ARM64 with ARM32 stuff.
> >
> > So, frankly, find a different way to this.  We don't need to needlessly
> > waste HWCAP bits on ARM32.
> 
> So my idea was to use HWCAP2 bits instead ...

The introduction of HWCAP2 on ARM32 could be seen as ARM64 pollution 
just as well.

But someone connected with ARM Ltd said that 32-bit-only ARMv8 
implementations are likely to show up.  Therefore Russell's argument 
can't hold as ARM32 support won't stop with ARMv7.

Still, Russell also remarked that the bits you added took a significant 
portion of the remaining HWCAP bits, which you fixed by adding HWCAP2 to 
ARM32.

So far so good.

You also decided to put the new crypto bits into HWCAP2.  I have no 
actual objection with that either.

What makes me wonder is Catalin's affirmation about putting those new 
bits into HWCAP2 making future extensions possible with old glibc 
versions that don't have knowledge about HWCAP2.  That is what I don't 
get the pertinence of.


Nicolas

Re: [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions

[Catalin Marinas]

On Mon, Jan 20, 2014 at 07:42:36PM +0000, Nicolas Pitre wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> > Quoting Russell:
> > 
> > On 18 December 2013 12:42, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > The point is that they'll never appear on an ARMv7 implementation because
> > > they're not part of the ARMv7 architecture.  I see no point in needlessly
> > > polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> > > no point in polluting ARM64 with ARM32 stuff.
> > >
> > > So, frankly, find a different way to this.  We don't need to needlessly
> > > waste HWCAP bits on ARM32.
> > 
> > So my idea was to use HWCAP2 bits instead ...
[...]
> You also decided to put the new crypto bits into HWCAP2.  I have no 
> actual objection with that either.
> 
> What makes me wonder is Catalin's affirmation about putting those new 
> bits into HWCAP2 making future extensions possible with old glibc 
> versions that don't have knowledge about HWCAP2.  That is what I don't 
> get the pertinence of.

I was looking for a justification for not touching HWCAP and instead
going directly to HWCAP2. Some user application compiled against an old
glibc could still access HWCAP via getauxval() but not HWCAP2. So that's
not for old glibc using new HWCAP bits itself.

A recent example is the HWCAP_EVSTRM which is ARMv7 only, some
application could implement some user space polling using WFE (I think
I've heard about smarter user locking in PostgreSQL). We may get other
ARMv7 ideas in the future or CPU implementations with features not
covered by the ARM ARM.

But if we decide to keep ARMv8 bits in HWCAP2, it's fine by me, I
already acked these patches. It's up to Russell whether he wants to take
them in this form or not.

-- 
Catalin