[PATCH] arm64: signal: Update sigcontext reservations table

[Mark Brown]

On Mon, Jul 29, 2024 at 04:51:27PM +0100, Dave Martin wrote:
> On Mon, Jul 29, 2024 at 03:53:12PM +0100, Mark Brown wrote:

> > There's no mutual exclusion here, but since we only generate the data
> > payloads if userspace explicitly chooses to enter streaming mode or
> > enable ZA/ZT0 I would tend to class any VL dependent size there as opt
> > in and only include the base structs.  I'm not clear what your thinking
> > is with specifying them for some vector lengths.

> The basic test would be: can non large-sigframe-aware program blow up
> if ld.so links it against a library that uses SME internally?

> There is no absolute guarantee here, but firstly well-behaved libraries
> either shouldn't mess with the vector length or should block signals
> around critical sections (or create worker threads that block all
> signals), and secondly a paranoid program could preempt the prctl()
> function to prevent the vector length being changed.

I think anything that goes and fiddles with the vector length
dynamically from a library is sufficiently adventurous that it's kind of
out of scope here.

> There is no way to prevent SM/ZA twiddling though, IIUC.  Within the
> AArch64 application programmer's model and PCS rules, user code should
> be able to do whatever it likes without worrying about breaking other
> code.

> So a program must be prepared to accept the largest possible SME
> sigframe, given the current streaming SME vector length.

> Ditto all other features that can be used without an explicit call to
> enable (or fatten) them.

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...
-------------- 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/20240729/e08bb107/attachment.sig>