linux-kernel - sve_user

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <785d7bc29da6bff0dceeb712c24601fd@codeaurora.org>
Date:   Thu, 20 May 2021 16:02:03 -0700
From:   psodagud@...eaurora.org
To:     catalin.marinas@....com, will@...nel.org, Dave.Martin@....com,
        amit.kachhap@....com
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: sve_user_discard

Hi All,

This is regarding sve_user_disable(CPACR_EL1_ZEN_EL0EN) on every system 
call.  If a userspace task is using SVE instructions and making sys 
calls in between, it would impact the performance of the thread. On 
every SVE instructions after SVC/system call, it would trap to EL1.

I think by setting CPACR_EL1_ZEN_EL0EN flag,  the processor faults when 
it runs an SVE instruction. This approach may be taken as part of FPSIMD 
registers switching optimizations.  Can below portion of the code use 
thread.fpsimd_cpu and fpsimd_last_state variables to avoid clearing 
CPACR_EL1_ZEN_EL0EN for this kind of use cases?

static inline void sve_user_discard(void)
{
	if (!system_supports_sve())
		return;

	clear_thread_flag(TIF_SVE);

	/*
	 * task_fpsimd_load() won't be called to update CPACR_EL1 in
	 * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
	 * happens if a context switch or kernel_neon_begin() or context
	 * modification (sigreturn, ptrace) intervenes.
	 * So, ensure that CPACR_EL1 is already correct for the fast-path case.
	 */
	sve_user_disable();
}

-Thanks, Prasad