All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
	catalin.marinas@arm.com, will@kernel.org,
	linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, jserv@ccns.ncku.edu.tw
Subject: Re: [PATCH 1/1] crypto: arm64/aes-neonbs - Move key expansion off the stack
Date: Thu, 5 Mar 2026 11:38:47 -0800	[thread overview]
Message-ID: <20260305193847.GG2796@quark> (raw)
In-Reply-To: <20260305183229.150599-2-yphbchou0911@gmail.com>

On Fri, Mar 06, 2026 at 02:32:24AM +0800, Cheng-Yang Chou wrote:
> aesbs_setkey() and aesbs_cbc_ctr_setkey() trigger -Wframe-larger-than=
> warnings due to struct crypto_aes_ctx being allocated on the stack,
> causing the frame size to exceed 1024 bytes.
> 
> Allocate struct crypto_aes_ctx on the heap instead to reduce stack
> usage. Use a goto-based cleanup path to ensure memzero_explicit() and
> kfree() are always called.
> 
> Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
> ---
>  arch/arm64/crypto/aes-neonbs-glue.c | 39 ++++++++++++++++++-----------
>  1 file changed, 25 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
> index cb87c8fc66b3..a24b66fd5cad 100644
> --- a/arch/arm64/crypto/aes-neonbs-glue.c
> +++ b/arch/arm64/crypto/aes-neonbs-glue.c
> @@ -76,19 +76,25 @@ static int aesbs_setkey(struct crypto_skcipher *tfm, const u8 *in_key,
>  			unsigned int key_len)
>  {
>  	struct aesbs_ctx *ctx = crypto_skcipher_ctx(tfm);
> -	struct crypto_aes_ctx rk;
> +	struct crypto_aes_ctx *rk;
>  	int err;
>  
> -	err = aes_expandkey(&rk, in_key, key_len);
> +	rk = kmalloc(sizeof(*rk), GFP_KERNEL);
> +	if (!rk)
> +		return -ENOMEM;
> +
> +	err = aes_expandkey(rk, in_key, key_len);
>  	if (err)
> -		return err;
> +		goto out;
>  
>  	ctx->rounds = 6 + key_len / 4;
>  
>  	scoped_ksimd()
> -		aesbs_convert_key(ctx->rk, rk.key_enc, ctx->rounds);
> -
> -	return 0;
> +		aesbs_convert_key(ctx->rk, rk->key_enc, ctx->rounds);
> +out:
> +	memzero_explicit(rk, sizeof(*rk));
> +	kfree(rk);
> +	return err;
>  }
>  
>  static int __ecb_crypt(struct skcipher_request *req,
> @@ -133,22 +139,27 @@ static int aesbs_cbc_ctr_setkey(struct crypto_skcipher *tfm, const u8 *in_key,
>  			    unsigned int key_len)
>  {
>  	struct aesbs_cbc_ctr_ctx *ctx = crypto_skcipher_ctx(tfm);
> -	struct crypto_aes_ctx rk;
> +	struct crypto_aes_ctx *rk;
>  	int err;
>  
> -	err = aes_expandkey(&rk, in_key, key_len);
> +	rk = kmalloc(sizeof(*rk), GFP_KERNEL);
> +	if (!rk)
> +		return -ENOMEM;
> +
> +	err = aes_expandkey(rk, in_key, key_len);
>  	if (err)
> -		return err;
> +		goto out;
>  
>  	ctx->key.rounds = 6 + key_len / 4;
>  
> -	memcpy(ctx->enc, rk.key_enc, sizeof(ctx->enc));
> +	memcpy(ctx->enc, rk->key_enc, sizeof(ctx->enc));
>  
>  	scoped_ksimd()
> -		aesbs_convert_key(ctx->key.rk, rk.key_enc, ctx->key.rounds);
> -	memzero_explicit(&rk, sizeof(rk));
> -
> -	return 0;
> +		aesbs_convert_key(ctx->key.rk, rk->key_enc, ctx->key.rounds);
> +out:
> +	memzero_explicit(rk, sizeof(*rk));
> +	kfree(rk);
> +	return err;
>  }

Instead of memzero_explicit() followed by kfree(), just use
kfree_sensitive().

Also, single patches should not have a cover letter.  Just send a single
patch email with all the details in the patch itself.

As for the actual change, I guess it's okay for now.  Ideally we'd
refactor the aes-bs key preparation to not need temporary space.

- Eric


  reply	other threads:[~2026-03-05 19:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-05 18:32 [PATCH 0/1] crypto: arm64/aes-neonbs - Move key expansion off the stack Cheng-Yang Chou
2026-03-05 18:32 ` [PATCH 1/1] " Cheng-Yang Chou
2026-03-05 19:38   ` Eric Biggers [this message]
2026-03-06  5:46     ` Cheng-Yang Chou
2026-03-06  5:54       ` Eric Biggers

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=20260305193847.GG2796@quark \
    --to=ebiggers@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jserv@ccns.ncku.edu.tw \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=yphbchou0911@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.