arm64: signal: Report signal frame size to userspace via auxv

Stateful CPU architecture extensions may require the signal frame to grow to a size that exceeds the arch's MINSIGSTKSZ #define. However, changing this #define is an ABI break.

To allow userspace the option of determining the signal frame size in a more forwards-compatible way, this patch adds a new auxv entry tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame size that the process can observe during its lifetime.

If AT_MINSIGSTKSZ is absent from the aux vector, the caller can assume that the MINSIGSTKSZ #define is sufficient. This allows for a consistent interface with older kernels that do not provide AT_MINSIGSTKSZ.

The idea is that libc could expose this via sysconf() or some similar mechanism.

There is deliberately no AT_SIGSTKSZ. The kernel knows nothing about userspace's own stack overheads and should not pretend to know.

Stateful CPU architecture extensions may require the signal frame to grow to a size that exceeds the arch's MINSIGSTKSZ #define. However, changing this #define is an ABI break.

To allow userspace the option of determining the signal frame size in a more forwards-compatible way, this patch adds a new auxv entry tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame size that the process can observe during its lifetime.

If AT_MINSIGSTKSZ is absent from the aux vector, the caller can assume that the MINSIGSTKSZ #define is sufficient. This allows for a consistent interface with older kernels that do not provide AT_MINSIGSTKSZ.

The idea is that libc could expose this via sysconf() or some similar mechanism.

There is deliberately no AT_SIGSTKSZ. The kernel knows nothing about userspace's own stack overheads and should not pretend to know.

arch/arm64/include/asm/elf.h +3 -0

index fac1c4d..8cf112b 100644
@@ -121,6 +121,9 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
 typedef unsigned long elf_greg_t;
 
 #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))

@@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
 do {									\
 	NEW_AUX_ENT(AT_SYSINFO_EHDR,					\

Hi Dave,

Cheers for respinning this. Just one observation below, which I only just thought about.

Quoted 20 lines · Dave Martin

Stateful CPU architecture extensions may require the signal frame to grow to a size that exceeds the arch's MINSIGSTKSZ #define. However, changing this #define is an ABI break.

To allow userspace the option of determining the signal frame size in a more forwards-compatible way, this patch adds a new auxv entry tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame size that the process can observe during its lifetime.

If AT_MINSIGSTKSZ is absent from the aux vector, the caller can assume that the MINSIGSTKSZ #define is sufficient. This allows for a consistent interface with older kernels that do not provide AT_MINSIGSTKSZ.

The idea is that libc could expose this via sysconf() or some similar mechanism.

There is deliberately no AT_SIGSTKSZ. The kernel knows nothing about userspace's own stack overheads and should not pretend to know.

[...]

Quoted 25 lines

arch/arm64/include/asm/elf.h +10 -0

index fac1c4d..8cf112b 100644
@@ -121,6 +121,9 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
 typedef unsigned long elf_greg_t;
 
 #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))

@@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
 do {									\
 	NEW_AUX_ENT(AT_SYSINFO_EHDR,					\
 		    (elf_addr_t)current->mm->context.vdso);		\
+									\
+	/*								\
+	 * Should always be nonzero unless there's a kernel bug.	\
+	 * If we haven't determined a sensible value to give to		\
+	 * userspace, omit the entry:					\
+	 */								\
+	if (likely(signal_minsigstksz))					\

arch/arm64/include/asm/elf.h typedef struct user_fpsimd_state elf_fpregset_t; · line 162

Quoted 2 lines

arch/arm64/include/asm/elf.h +1 -0

+		NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz);	\
 } while (0)

I think this is the desired behaviour, but now I'm worried that we're forced to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the ELF loader deals with this gracefuly, the FDPIC loader looks a lot less robust (in particular, my reading is that it decrements the stack pointer and then pushes these entries in reverse order by overloading NEW_AUX_ENT).

Quoted 26 lines · Will Deacon

Quoted 25 lines · Dave Martin

arch/arm64/include/asm/elf.h +10 -0

index fac1c4d..8cf112b 100644
@@ -121,6 +121,9 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
 typedef unsigned long elf_greg_t;
 
 #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))

@@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
 do {									\
 	NEW_AUX_ENT(AT_SYSINFO_EHDR,					\
 		    (elf_addr_t)current->mm->context.vdso);		\
+									\
+	/*								\
+	 * Should always be nonzero unless there's a kernel bug.	\
+	 * If we haven't determined a sensible value to give to		\
+	 * userspace, omit the entry:					\
+	 */								\
+	if (likely(signal_minsigstksz))					\

Quoted 8 lines

arch/arm64/include/asm/elf.h typedef struct user_fpsimd_state elf_fpregset_t; · line 162

Quoted 2 lines

arch/arm64/include/asm/elf.h +1 -0

+		NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz);	\
 } while (0)

I think this is the desired behaviour, but now I'm worried that we're forced to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the ELF loader deals with this gracefuly, the FDPIC loader looks a lot less robust (in particular, my reading is that it decrements the stack pointer and then pushes these entries in reverse order by overloading NEW_AUX_ENT).

config BINFMT_ELF_FDPIC

	/* ... */
	depends on (ARM || (SUPERH32 & !MMU) || C6X)

The FDPIC loader seems to assume it's 32-bit only and also looks broken with regard to auxv:

	/* force 16 byte _final_ alignment here for generality */

#define DLINFO_ITEMS 15

/* ... */

		nr = 0;
		csp -= 2 * sizeof(unsigned long);
		NEW_AUX_ENT(AT_EXECFD, ...);
	}

/* ... */

	csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
	NEW_AUX_ENT(AT_HWCAP,   ELF_HWCAP);
#ifdef ELF_HWCAP2
	NEW_AUX_ENT(AT_HWCAP2,  ELF_HWCAP2);
#endif
	/* 14 more NEW_AUX_ENT() */

Looks like commit 2171364d1a92 ("powerpc: Add HWCAP2 aux entry") added HWCAP2 without ensuring that space is reserved.

I can try to draft a patch to handle the auxv in a more sane way for FDPIC, but either way I don't see that it should be relevant to arm64.

AT_IGNORE feels like a bit of a fig leaf, but it's harmless enough. I'm happy to add it if you prefer.

Quoted 36 lines · Dave Martin

Quoted 34 lines · Will Deacon

Quoted 17 lines · Dave Martin

arch/arm64/include/asm/elf.h +3 -0

index fac1c4d..8cf112b 100644
@@ -121,6 +121,9 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
 typedef unsigned long elf_greg_t;
 
 #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))

@@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
 do {									\
 	NEW_AUX_ENT(AT_SYSINFO_EHDR,					\

arch/arm64/include/asm/elf.h typedef struct user_fpsimd_state elf_fpregset_t; · line 162

Quoted 10 lines

arch/arm64/include/asm/elf.h +8 -0

 		    (elf_addr_t)current->mm->context.vdso);		\
+									\
+	/*								\
+	 * Should always be nonzero unless there's a kernel bug.	\
+	 * If we haven't determined a sensible value to give to		\
+	 * userspace, omit the entry:					\
+	 */								\
+	if (likely(signal_minsigstksz))					\
+		NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz);	\
 } while (0)

I think this is the desired behaviour, but now I'm worried that we're forced to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the ELF loader deals with this gracefuly, the FDPIC loader looks a lot less robust (in particular, my reading is that it decrements the stack pointer and then pushes these entries in reverse order by overloading NEW_AUX_ENT).

Quoted 3 lines

config BINFMT_ELF_FDPIC

	/* ... */
	depends on (ARM || (SUPERH32 & !MMU) || C6X)

Ok, that's a relief. The checkpoint stuff is still a bit worrying though (prctl_set_mm_map).

Quoted 30 lines

The FDPIC loader seems to assume it's 32-bit only and also looks broken with regard to auxv:

	/* force 16 byte _final_ alignment here for generality */

#define DLINFO_ITEMS 15

/* ... */

		nr = 0;
		csp -= 2 * sizeof(unsigned long);
		NEW_AUX_ENT(AT_EXECFD, ...);
	}

/* ... */

	csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
	NEW_AUX_ENT(AT_HWCAP,   ELF_HWCAP);
#ifdef ELF_HWCAP2
	NEW_AUX_ENT(AT_HWCAP2,  ELF_HWCAP2);
#endif
	/* 14 more NEW_AUX_ENT() */

Looks like commit 2171364d1a92 ("powerpc: Add HWCAP2 aux entry") added HWCAP2 without ensuring that space is reserved.

I can try to draft a patch to handle the auxv in a more sane way for FDPIC, but either way I don't see that it should be relevant to arm64.

Quoted 2 lines

AT_IGNORE feels like a bit of a fig leaf, but it's harmless enough. I'm happy to add it if you prefer.

The only userspace code I could find that uses it is something that prints out auxv, but I'd still better spitting it out so we don't have to worry about being smaller than AT_VECTOR_SIZE_ARCH.