[PATCH] arm64: signal: Update sigcontext reservations table

[Mark Brown]

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.

> 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.
-------------- 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/28ef38b5/attachment.sig>