[PATCH] arm64: signal: Update sigcontext reservations table

[Dave Martin]

Hi,

On Mon, Jul 29, 2024 at 06:01:02PM +0100, Mark Brown wrote:
> 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.

Yes.  There are ways to do it (mostly) safely, but it's fiddly, and it
seemed too hard to make promises that would be useful to general
purpose userspace code.

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

I think that the opt-in has to be per running process.

How userspace decides whether to opt in is outside the scope of the
kernel, so the original SVE design at least tried to make things safe
by default, using the sve_default_vector_length clamp.

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.


In the future, distros might consider the codebase fully "large
sigframe aware", and increase sve_default_vector_length so that all
processes are opted in without having to do anything; that amounts to
a system-level opt-in.

Similarly for SME.


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.

If some feature needs a prctl() to enable it when first upstreamed,
then it's probably best to leave it up to ld.so and the libc startup
code to decide whether and when to call it.  Even if the kernel some
day can do this automatically based on ELF properties or something,
we'd still need to be backwards compatible.  If the "turn on" call
requires parameters, then something in userspace would need to use
it explicitly anyway.

Not sure whether any of this simplifies the discussion...

Cheers
---Dave