[PATCH] arm64: signal: Update sigcontext reservations table

[Dave Martin]

On Mon, Jul 29, 2024 at 03:53:12PM +0100, Mark Brown wrote:
> On Mon, Jul 29, 2024 at 03:41:49PM +0100, Dave Martin wrote:
> 
> > If Mark in particular can double-check the SME impact, that would be
> > appreciated.
> 
> ...
> 
> > Additional SME note: since userspace can freely switch in and out of
> > streaming SVE mode and freely enable/disable ZA and ZT0, I'm assuming
> > that none of sve_context, za_context and zt_context are mutually
> > exclusive, but please shout if I have confused myself here.
> 
> 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.

OK

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.

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.

Cheers
---Dave