Re: [PATCH v3 09/10] crypto: safexcel - Rework cleanup of sensitive structs in safexcel_aead_setkey

Antoine Tenart <[email protected]>
Newsgroups org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel
Message-ID <anR_pXCLY4He5sj6@kwain>
On Thu, Aug 06, 2026 at 10:18:12AM +0200, Thomas Huth wrote:
> On 06/08/2026 10.10, Antoine Tenart wrote:
> > On Wed, Aug 05, 2026 at 01:57:47PM +0200, Thomas Huth wrote:
> >> From: Thomas Huth <[email protected]>
> >>
> >> The crypto_authenc_keys structure only contains pointers to keys,
> >> but not the key data itself. So explicitly clearing the structure
> >> at the end of safexcel_aead_setkey() is not really necessary.
> >>
> >> On the other hand, the crypto_aes_ctx might contain sensitive information,
> >> so this structure should be cleaned up at the end instead. Do this
> >> now via the new __cleanup(aes_zeroize_ctx) marker.
> > 
> > Looking at other crypto drivers it seems zeroing the key pointers was
> > explicitly added (sometimes later) and my impression is a good chunk of
> > the users are zeroing it. I don't know whether removing that is fine or
> > not, my limited understanding is that provides in-depth defense against
> > leaking were the key reside in memory. Would love to see an explicit
> > statement from someone with that knowledge.
> 
> It has been suggested by Eric here (unless I got him wrong):
> 
>   https://lore.kernel.org/linux-crypto/[email protected]/
> 
> ... I should have maybe added that link to this patch description ...

Thanks for the link! Feel free to add it or not in the next revision.

> > (On the other hand mixing gotos and __cleanup is not advised but is that
> > an issue here? Or if zeroing crypto_authenc_keys is actually important
> > can we use __cleanup too?).
> > 
> >> --- a/drivers/crypto/inside-secure/safexcel_cipher.c
> >> +++ b/drivers/crypto/inside-secure/safexcel_cipher.c
> >> @@ -407,17 +407,17 @@ static int safexcel_aead_setkey(struct crypto_aead *ctfm, const u8 *key,
> >>   	struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(tfm);
> >>   	struct safexcel_crypto_priv *priv = ctx->base.priv;
> >>   	struct crypto_authenc_keys keys;
> >> -	struct crypto_aes_ctx aes;
> >> -	int err = -EINVAL, i;
> >> +	struct crypto_aes_ctx aes __cleanup(aes_zeroize_ctx);
> >> +	int err, i;
> >>   	const char *alg;
> > 
> >> @@ -430,25 +430,25 @@ static int safexcel_aead_setkey(struct crypto_aead *ctfm, const u8 *key,
> >>   	case SAFEXCEL_DES:
> >>   		err = verify_aead_des_key(ctfm, keys.enckey, keys.enckeylen);
> >>   		if (unlikely(err))
> >> -			goto badkey;
> >> +			return err;
> >>   		break;
> >>   	case SAFEXCEL_3DES:
> >>   		err = verify_aead_des3_key(ctfm, keys.enckey, keys.enckeylen);
> >>   		if (unlikely(err))
> >> -			goto badkey;
> >> +			return err;
> >>   		break;
> >>   	case SAFEXCEL_AES:
> >>   		err = aes_expandkey(&aes, keys.enckey, keys.enckeylen);
> >>   		if (unlikely(err))
> >> -			goto badkey;
> >> +			return err;
> >>   		break;
> >>   	case SAFEXCEL_SM4:
> >>   		if (unlikely(keys.enckeylen != SM4_KEY_SIZE))
> >> -			goto badkey;
> >> +			return err;
> > 
> > 'err' is uninitialized here. You can use '-EINVAL' instead.
> Oops, good catch, thanks! I will fix it in the next version (assuming that 
> removing the memzero_explicit is ok and we'll keep this patch...)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.