Received-SPF: pass (google.com: domain of linux-kernel+bounces-44775-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 30 Jan 2024 14:53:45 +0000
From: Mark Brown <broonie@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] arm64/signal: Don't assume that TIF_SVE means we saved
 SVE state
Message-ID: <7027bd80-1fea-493a-83d7-ffef4e548f08@sirena.org.uk>
References: <20240119-arm64-sve-signal-regs-v1-1-b9fd61b0289a@kernel.org>
 <20240130115107.GB13551@willie-the-truck>
 <b0ed6698-bc65-48fb-96b8-0cd077448196@sirena.org.uk>
 <ZbkLY+gz7Az1OgNK@e133380.arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="W+TBP/Hhe0/VKR6a"
Content-Disposition: inline
In-Reply-To: <ZbkLY+gz7Az1OgNK@e133380.arm.com>


--W+TBP/Hhe0/VKR6a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

--W+TBP/Hhe0/VKR6a
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmW5DXgACgkQJNaLcl1U
h9B8Jwf/bbGTk8dY3wv6i5yLgXvA8OX0zJOWfZewnjQeBtwiZSZLA7nl0VKHB4u1
B3ZpNoFsiFy3mrLJnR3yRXZj8UttcAuGEYM4YqYXik8h0Xcx44kIjlX93iANunfp
X1+WyrOXFaY9DYv3IOnn2YdBb8ssafW3CDTTs7F5MHwf4biheXe1CuGipJHGv2nb
DH2tlhGWKszWBl6tY0bl905s0Wvw2ggNM0lsFFheBb8IPd+idcNSldYMNU09yIae
9kIgQ6XgCSQLasL5PUhBBz1T1QDnY0+8iqkZceEcYqUYZjWM+v/cBJnlrR1m3C09
1YGX+yP+cL8f25SHy4eHhcbUDFN2jw==
=eCS8
-----END PGP SIGNATURE-----

--W+TBP/Hhe0/VKR6a--