linux-kernel - Re: [PATCH] arm64/signal: Don't assume that TIF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 30 Jan 2024 14:53:45 +0000
From: Mark Brown <broonie@...nel.org>
To: Dave Martin <Dave.Martin@....com>
Cc: Will Deacon <will@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] arm64/signal: Don't assume that TIF_SVE means we saved
 SVE state

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)