Message-Id: <20250820-arm64-sme-ptrace-sme-only-v1-0-f7c22b2871f8@kernel.org>
Date: Wed, 20 Aug 2025 19:29:02 +0100
From: Mark Brown <broonie@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>, 
 Will Deacon <will@...nel.org>, Shuah Khan <shuah@...nel.org>, 
 Jonathan Corbet <corbet@....net>, Oleg Nesterov <oleg@...hat.com>
Cc: 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, 
 Mark Brown <broonie@...nel.org>
Subject: [PATCH 0/5] arm64/sme: Support disabling streaming mode via ptrace
 on SME only systems

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 could 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 suceed while
reads of NT_ARM_SVE will fail. Read/write access to the FPSIMD registers in
non-streaming mode is available via REGSET_FPR.

The aim is 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.

The series starts with some enhancements to sve-ptrace to cover some
further corners of existing behaviours in order to reduce the risk of
inadvertent changes, implements the proposed new ABI, then extends both
sve-ptrace and fp-ptrace to exercise it.

Signed-off-by: Mark Brown <broonie@...nel.org>
---
Mark Brown (5):
      kselftest/arm64: Verify that we reject out of bounds VLs in sve-ptrace
      kselftest/arm64: Check that unsupported regsets fail in sve-ptrace
      arm64/sme: Support disabling streaming mode via ptrace on SME only systems
      kselftst/arm64: Test NT_ARM_SVE FPSIMD format writes on non-SVE systems
      kselftest/arm64: Cover disabling streaming mode without SVE in fp-ptrace

 Documentation/arch/arm64/sve.rst              |   5 +
 arch/arm64/kernel/ptrace.c                    |  40 ++++++--
 tools/testing/selftests/arm64/fp/fp-ptrace.c  |   5 +-
 tools/testing/selftests/arm64/fp/sve-ptrace.c | 139 +++++++++++++++++++++++++-
 4 files changed, 177 insertions(+), 12 deletions(-)
---
base-commit: 768361ab16ce943ef3577cea204dc81aa4a47517
change-id: 20250717-arm64-sme-ptrace-sme-only-1fb850600ea0
prerequisite-change-id: 20250808-arm64-fp-trace-macro-02ede083da51

Best regards,
--  
Mark Brown <broonie@...nel.org>

Powered by blists - more mailing lists