linux-kernel - Re: [PATCH 1/4] arm64/sve: Remove bitrotted comment about syscall behaviour

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: <Za/e15zUOEaa1b7d@e133380.arm.com>
Date: Tue, 23 Jan 2024 15:44:23 +0000
From: Dave Martin <Dave.Martin@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Jonathan Corbet <corbet@....net>,
	linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Edmund Grimley-Evans <edmund.grimley-evans@....com>
Subject: Re: [PATCH 1/4] arm64/sve: Remove bitrotted comment about syscall
 behaviour

On Mon, Jan 22, 2024 at 08:41:51PM +0000, Mark Brown wrote:
> When we documented that we always clear state not shared with FPSIMD we

Where / when?

> didn't catch all of the places that mentioned that state might not be
> cleared, remove a lingering reference.
> 
> Reported-by: Edmund Grimley-Evans <edmund.grimley-evans@....com>
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  Documentation/arch/arm64/sve.rst | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/Documentation/arch/arm64/sve.rst b/Documentation/arch/arm64/sve.rst
> index 0d9a426e9f85..b45a2da19bf1 100644
> --- a/Documentation/arch/arm64/sve.rst
> +++ b/Documentation/arch/arm64/sve.rst
> @@ -117,11 +117,6 @@ the SVE instruction set architecture.
>  * The SVE registers are not used to pass arguments to or receive results from
>    any syscall.
>  
> -* In practice the affected registers/bits will be preserved or will be replaced
> -  with zeros on return from a syscall, but userspace should not make
> -  assumptions about this.  The kernel behaviour may vary on a case-by-case
> -  basis.
> -

This was originally an intentionally conservative statement, to allow
the kernel the flexibility to relax the register zeroing behaviour in
the future.  It would have permitted not always disabling a task's SVE
across a syscall, for example.  There were some concerns about security
and testability that meant that we didn't use this flexibility to begin
with.

If we are making an irrevocable commitment not to use this flexibility
ever, then this comment can go, but if we're not totally sure then I
think it would be harmless to keep it (?)

(Feel free to point me to the relevant past discussion that I may have
missed.)

[...]

Cheers
---Dave