[PATCH] arm64: signal: Update sigcontext reservations table

[Dave Martin]

On Tue, Jul 30, 2024 at 02:22:47PM +0100, Mark Brown wrote:
> On Tue, Jul 30, 2024 at 01:51:22PM +0100, Dave Martin wrote:
> > On Mon, Jul 29, 2024 at 06:01:02PM +0100, Mark Brown wrote:
> 
> > > Hrm, indeed.  I think while you're at clarifying this it'd be good to
> > > clarify what we're thinking of as opting in - is it userspace as a whole
> > > we're thinking of or is it a specific dynamically linked binary?
> > > There's also things like the dynamic linker and code generation options
> > > in the compiler to worry about here...
> 
> > I think that the opt-in has to be per running process.
> 
> Yes, I tend to agree.
> 
> > Since making the opt-in decision correctly requires some effort, I
> > expected that most programs just won't bother and won't opt in unless
> > they actually need a given feature in order to work at all.
> 
> 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.

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

Cheers
---Dave