linux-kernel - Re: [PATCH 3/5] arm64/sme: Support disabling streaming mode via ptrace on SME only systems

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]

Message-ID: <aMvxkzg_LT4C4Quh@willie-the-truck>
Date: Thu, 18 Sep 2025 12:48:35 +0100
From: Will Deacon <will@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Shuah Khan <shuah@...nel.org>, Jonathan Corbet <corbet@....net>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Rutland <mark.rutland@....com>,
	David Spickett <david.spickett@....com>,
	Thiago Jung Bauermann <thiago.bauermann@...aro.org>,
	Luis Machado <luis.machado.foss@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH 3/5] arm64/sme: Support disabling streaming mode via
 ptrace on SME only systems

On Wed, Aug 20, 2025 at 07:29:05PM +0100, Mark Brown wrote:
> Currently it is not possible to disable streaming mode via ptrace on SME
> only systems, the interface for doing this is to write via NT_ARM_SVE but
> such writes will be rejected on a system without SVE support. Enable this
> functionality by allowing userspace to write SVE_PT_REGS_FPSIMD format data
> via NT_ARM_SVE with the vector length set to 0 on SME only systems. Such
> writes currently error since we require that a vector length is specified
> which should minimise the risk that existing software is relying on current
> behaviour.
> 
> Reads are not supported since I am not aware of any use case for this and
> there is some risk that an existing userspace application may be confused if
> it reads NT_ARM_SVE on a system without SVE. Existing kernels will return
> FPSIMD formatted register state from NT_ARM_SVE if full SVE state is not
> stored, for example if the task has not used SVE. Returning a vector length
> of 0 would create a risk that software would try to do things like allocate
> space for register state with zero sizes, while returning a vector length of
> 128 bits would look like SVE is supported. It seems safer to just not make
> the changes to add read support.
> 
> It remains possible for userspace to detect a SME only system via the ptrace
> interface only since reads of NT_ARM_SSVE and NT_ARM_ZA will succeed while
> reads of NT_ARM_SVE will fail. Read/write access to the FPSIMD registers in
> non-streaming mode is available via REGSET_FPR.
> 
> sve_set_common() already avoids allocating SVE storage when doing a FPSIMD
> formatted write and allocating SME storage when doing a NT_ARM_SVE write so
> we change the function to validate the new case and skip setting a vector
> length for it.
> 
> The aim is to make a minimally invasive change, no operation that would
> previously have succeeded will be affected, and we use a previously
> defined interface in new circumstances rather than define completely new
> ABI.
> 
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  Documentation/arch/arm64/sve.rst |  5 +++++
>  arch/arm64/kernel/ptrace.c       | 40 +++++++++++++++++++++++++++++++++-------
>  2 files changed, 38 insertions(+), 7 deletions(-)

It would be good to have an Ack from the userspace side (GDB?) so that
we know that the minimal ABI change you're proposing is sufficient.

In the meantime, I'll pick up the first two selftests as they are
independent of this part.

Will