Received-SPF: pass (google.com: domain of linux-kernel+bounces-62063-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 12 Feb 2024 17:09:24 +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>,
	Oleg Nesterov <oleg@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
	Doug Anderson <dianders@chromium.org>
Subject: Re: [PATCH] arm64/sve: Lower the maximum allocation for the SVE
 ptrace regset
Message-ID: <b0858303-8289-4371-be62-27da98d57020@sirena.org.uk>
References: <20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org>
 <ZcpMabqH+VZv6RCZ@e133344.arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jbFy/Os4nITzwxhJ"
Content-Disposition: inline
In-Reply-To: <ZcpMabqH+VZv6RCZ@e133344.arm.com>


--jbFy/Os4nITzwxhJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 12, 2024 at 04:50:49PM +0000, Dave Martin wrote:
> On Sat, Feb 03, 2024 at 12:16:49PM +0000, Mark Brown wrote:

> > -		.n = DIV_ROUND_UP(SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE),
> > +		.n = DIV_ROUND_UP(SVE_PT_SIZE(ARCH_SVE_VQ_MAX,
> > +					      SVE_PT_REGS_SVE),
> >  				  SVE_VQ_BYTES),

> Do we need an actual check somewhere that we don't bust this limit?

..

> Userspace could specify vl > sve_vl_from_vq(ARCH_SVE_VQ_MAX) in
> PTRACE_SETREGSET; I'm not sure exactly what happens there.

We already have validation against the actual enumerated limits for the
system by virtue of setting the vector length to whatever is specified
so we'll limit any overly large vector length down to something we can
actually support and then reject an attempt to supply register data if
we changed the VL from what the user specified.

> Since ZCR_ELx_LEN_MASK was changed from 0x1ff to 0xf, it looks like the
> kernel itself will not generate an overlarge VL, although it feels a bit
> like this guarantee arrives by accident.
> Could ARCH_SVE_VQ_MAX be based on ZCR_ELx_LEN_MASK instead?

I guess.

--jbFy/Os4nITzwxhJ
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXKUMMACgkQJNaLcl1U
h9AQ4Af8DfUN/JUR9xzcRi0ChS2rH/IdTTT/8uHAChzJ4PnIInlgEj1ZaxsM9s4y
oyqCjwEekMQlsQ3BE9cZRyn38fDS5r6KToTkfZnjMAWDU6YtXvVdPBIwZ8RWospt
+TtQu4NOV6ts8cUd7wNXQeFjn7aPTLuPfHnYUFM4XdAkF0501XcVWm/UT02FV1q/
Dpyoa2LlMpNtiDw4zrbZ3G+7BlOK/l5qqLYFw4Xb0IDPMxv8QvsI0U6zikhWj0y8
0eI9xyFJVU1StQVo1AI2NGWcGGDld4RwCPLtBuUoacf+T6Y43crcZc7/Qmx3YC+V
EeHbf/txRxdjT4EVbvxaQrAcE9O+AQ==
=vwAN
-----END PGP SIGNATURE-----

--jbFy/Os4nITzwxhJ--