[PATCH] arm64/signal: Don't assume that TIF_SVE means we saved SVE state

[Mark Brown]

On Tue, Jan 30, 2024 at 02:44:51PM +0000, Dave Martin wrote:
> On Tue, Jan 30, 2024 at 02:09:34PM +0000, Mark Brown wrote:

> > That said if this is preempted ptrace *could* come in and rewrite the
> > data or at worst change the vector length (which could leave us with
> > sve_state deallocated or a different size, possibly while we're in the
> > middle of accessing it).  This could also happen with the existing check
> > for TIF_SVE so I don't think there's anything new here - AFAICT this has
> > always been an issue with the vector code, unless I'm missing some
> > bigger thing which excludes ptrace.  I think any change that's needed
> > there won't overlap with this one, I'm looking.

> I'm pretty sure that terrible things will happen treewide if ptrace can
> ever access or manipulate the internal state of a _running_ task.

> I think the logic is that any ptrace call that can access or manipulate
> the state of a task is gated on the task being ptrace-stopped.  Once we

...

> I haven't tracked down the smokeproof gun in the code yet, though.

Yes, exactly - this feels like something that surely must be handled
already with exclusion along the lines that you're describing but I
didn't yet spot exactly what the mechanism is.

> From memory, I think that the above forced flush was there to protect
> against the context switch code rather than ptrace, and guarantees that
> any change that ctxsw _might_ spontaneously make to the task state has
> already been done and dusted before we do the actual signal delivery.
> This may be a red herring so far as ptrace hazards are concerned.

Indeed, it's all about the current task and won't help at for ptrace.
-------------- 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/20240130/209373bd/attachment.sig>