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]
Date:   Thu, 20 Jul 2023 11:52:36 +0100
From:   Will Deacon <will@...nel.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Shuah Khan <shuah@...nel.org>,
        David Spickett <David.Spickett@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/3] arm64/fpsimd: Ensure SME storage is allocated after
 SVE VL changes

On Thu, Jul 13, 2023 at 09:06:04PM +0100, Mark Brown wrote:
> When we reconfigure the SVE vector length we discard the backing storage
> for the SVE vectors and then reallocate on next SVE use, leaving the SME
> specific state alone. This means that we do not enable SME traps if they
> were already disabled. That means that userspace code can enter streaming
> mode without trapping, putting the task in a state where if we try to save
> the state of the task we will fault.
> 
> Since the ABI does not specify that changing the SVE vector length disturbs
> SME state, and since SVE code may not be aware of SME code in the process,
> we shouldn't simply discard any ZA state. Instead immediately reallocate
> the storage for SVE if SME is active, and disable SME if we change the SVE
> vector length while there is no SME state active.

What is the advantage of keep the old behaviour in this case? In other
words, if it's acceptable to reallocate the state when SME is active, why
not just reallocate in all cases?

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ