[PATCH] arm64: signal: Update sigcontext reservations table

[Mark Brown]

On Tue, Jul 30, 2024 at 04:07:22PM +0100, Dave Martin wrote:
> On Tue, Jul 30, 2024 at 02:22:47PM +0100, Mark Brown wrote:

> > Well, it only requires thought if you do something that pays attention
> > to the signal frame layout - an awful lot of programs simply don't look
> > at the frame and so don't care.  There are things like userspace threads
> > which are particularly likely to be impacted but there's also a lot of
> > code that just handles a signal and returns without ever looking at the
> > frame.

> A program can't not pay attention to the sigframe _size_, i.e., even if
> you ignore the sigcontext, you still have to have allocated your stack
> big enough for it.

> That's the fundamental issue here.

A good percentage of programs manage to just use a default rather then
ever explicitly specifying or configuring anything themselves - C
programs will default to RLIMIT_STACK IIRC which is system configured
and generally set rather high.  It's true that anything that is
explicitly configuring stack sizes needs to worry about having enough
stack space for a signal frame on top of whatever else it's doing
(including anything limiting things system wide) but I'd be a bit
surprised if it were the common case that things were actually paying
attention.

> > > Ideally, the toolchain would mark binaries with the features they are
> > > compatible with, and try to load only compatible objects into the same
> > > process.  The ELF properties (as used for BTI etc.) provide a generic
> > > mechanism for this, but maybe we need to start pushing for labelling
> > > for other properties too.  The "can it trigger an oversized sigframe"
> > > property of an arch feature won't be obvious to the toolchain folks.

> > Hrm.  I can see this being fun with working out how the various
> > extensions compose with each other and how to turn things that the
> > toolchain usually wouldn't be aware of on.

> That's why I went for a simplified model:

> If a program exercises no opt-ins at all, then the sigframe must fit in
> MINSIGSTKSZ bytes.

> If the program exercises any opt-in at all, the sigframe is not
> guaranteed to fit in MINSIGSTKSZ bytes.  It's then the program's
> responsibility to pay attention to the real worst-case size advertised
> in AT_MINSIGSTKSZ in the auxv.

> As noted in the references, programs built against glibc-2.34 or later
> with -D_GNU_SOURCE (or -D_DYNAMIC_STACK_SIZE_SOURCE) will actually be
> using values based on the AT_MINSIGSTKSZ parameter rather than the old
> constant; uses of MINSIGSTKSZ and SIGSTKSZ that require it to be
> compile-time constant won't compile.

> The idea of the table in sigcontext.h was to help us track where opt-
> ins are needed, and what opt-in conditions exist.  This maybe wasn't as
> clear as it could have been.

I think some of it is the strength of the opt ins being considered.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240730/15b418e0/attachment.sig>