linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-crypto@vger.kernel.org, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2] arm64/simd: Avoid pointless clearing of FP/SIMD buffer
Date: Fri, 12 Dec 2025 18:29:29 -0800	[thread overview]
Message-ID: <20251213022929.GA71695@sol> (raw)
In-Reply-To: <20251209054848.998878-2-ardb@kernel.org>

On Tue, Dec 09, 2025 at 06:48:49AM +0100, Ard Biesheuvel wrote:
> The buffer provided to kernel_neon_begin() is only used if the task is
> scheduled out while the FP/SIMD is in use by the kernel, or when such a
> section is interrupted by a softirq that also uses the FP/SIMD.
> 
> IOW, this happens rarely, and even if it happened often, there is still
> no reason for this buffer to be cleared beforehand, which happens
> unconditionally, due to the use of a compound literal expression.
> 
> So define that buffer variable explicitly, and mark it as
> __uninitialized so that it will not get cleared, even when
> -ftrivial-auto-var-init is in effect.
> 
> This requires some preprocessor gymnastics, due to the fact that the
> variable must be defined throughout the entire guarded scope, and the
> expression
> 
>   ({ struct user_fpsimd_state __uninitialized st; &st; })
> 
> is problematic in that regard, even though the compilers seem to
> permit it. So instead, repeat for 'for ()' trick that is also used in
> the implementation of the guarded scope helpers.
> 
> Cc: Will Deacon <will@kernel.org>,
> Cc: Catalin Marinas <catalin.marinas@arm.com>,
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/arm64/include/asm/simd.h | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
> index 0941f6f58a14..69ecbd69ca8c 100644
> --- a/arch/arm64/include/asm/simd.h
> +++ b/arch/arm64/include/asm/simd.h
> @@ -48,6 +48,13 @@ DEFINE_LOCK_GUARD_1(ksimd,
>  		    kernel_neon_begin(_T->lock),
>  		    kernel_neon_end(_T->lock))
>  
> -#define scoped_ksimd()	scoped_guard(ksimd, &(struct user_fpsimd_state){})
> +#define __scoped_ksimd(_label)					\
> +	for (struct user_fpsimd_state __uninitialized __st;	\
> +	     true; ({ goto _label; }))				\
> +		if (0) {					\
> +_label:			break;					\
> +		} else scoped_guard(ksimd, &__st)
> +
> +#define scoped_ksimd()	__scoped_ksimd(__UNIQUE_ID(label))
>  
>  #endif
> 

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-fixes

I added:

    Fixes: 4fa617cc6851 ("arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack")

- Eric

      reply	other threads:[~2025-12-13  2:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09  5:48 [PATCH v2] arm64/simd: Avoid pointless clearing of FP/SIMD buffer Ard Biesheuvel
2025-12-13  2:29 ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251213022929.GA71695@sol \
    --to=ebiggers@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).