From: Thomas Huth <thuth@redhat.com>
To: Eric Biggers <ebiggers@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: [PATCH v3 01/13] lib/crypto: aes: Provide functions for zeroizing aes_key and aes_enckey
Date: Thu, 10 Sep 2026 14:41:20 +0200 [thread overview]
Message-ID: <20260910124138.417439-2-thuth@redhat.com> (raw)
In-Reply-To: <20260910124138.417439-1-thuth@redhat.com>
Some crypto functions need to zeroize their local aes_key or aes_enckey
structures after use to avoid leaking sensitive material on the stack.
Provide aes_zeroize_key() and aes_zeroize_enckey() helper functions that
can be used with __cleanup() to automatically zeroize the structs when
they go out of scope.
While we're at it, replace the memzero_explicit() calls in lib/crypto/aes.c
with the new helper functions.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
include/crypto/aes.h | 18 ++++++++++++++++++
lib/crypto/aes.c | 10 +++++-----
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/include/crypto/aes.h b/include/crypto/aes.h
index 3279cfa546085..9fe868161e1d3 100644
--- a/include/crypto/aes.h
+++ b/include/crypto/aes.h
@@ -101,6 +101,15 @@ struct aes_enckey {
union aes_enckey_arch k;
};
+/**
+ * aes_zeroize_enckey() - Zeroize an aes_enckey structure
+ * @key: The aes_enckey to zeroize
+ */
+static inline void aes_zeroize_enckey(struct aes_enckey *key)
+{
+ memzero_explicit(key, sizeof(*key));
+}
+
/**
* struct aes_key - An AES key prepared for encryption and decryption
* @aes_enckey: Common fields and the key prepared for encryption
@@ -115,6 +124,15 @@ struct aes_key {
union aes_invkey_arch inv_k;
};
+/**
+ * aes_zeroize_key() - Zeroize an aes_key structure
+ * @key: The aes_key to zeroize
+ */
+static inline void aes_zeroize_key(struct aes_key *key)
+{
+ memzero_explicit(key, sizeof(*key));
+}
+
/*
* Please ensure that the first two fields are 16-byte aligned
* relative to the start of the structure, i.e., don't move them!
diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c
index f1549839b3de0..07c1d912ac365 100644
--- a/lib/crypto/aes.c
+++ b/lib/crypto/aes.c
@@ -539,7 +539,7 @@ static void __init aes_fips_test(void)
if (memcmp(fips_test_data, data, sizeof(data)) != 0)
panic("aes: FIPS self-test failed (wrong plaintext)\n");
- memzero_explicit(&key, sizeof(key));
+ aes_zeroize_key(&key);
}
#if IS_ENABLED(CONFIG_CRYPTO_LIB_AES_CBC_MACS)
@@ -827,7 +827,7 @@ static void __init aes_ecb_fips_test(void)
if (memcmp(fips_test_data, data, sizeof(data)) != 0)
panic("aes: ECB FIPS self-test failed (wrong plaintext)\n");
- memzero_explicit(&key, sizeof(key));
+ aes_zeroize_key(&key);
}
#else /* CONFIG_CRYPTO_LIB_AES_ECB */
static inline void aes_ecb_fips_test(void)
@@ -1040,7 +1040,7 @@ static void __init aes_cbc_fips_test(void)
if (memcmp(fips_test_data, data, sizeof(data)) != 0)
panic("aes: CBC FIPS self-test failed (wrong plaintext)\n");
- memzero_explicit(&key, sizeof(key));
+ aes_zeroize_key(&key);
}
/* FIPS cryptographic algorithm self-test for AES-CBC-CTS */
@@ -1069,7 +1069,7 @@ static void __init aes_cbc_cts_fips_test(void)
if (memcmp(ptext, data, data_len) != 0)
panic("aes: CBC-CTS FIPS self-test failed (wrong plaintext)\n");
- memzero_explicit(&key, sizeof(key));
+ aes_zeroize_key(&key);
}
#else /* CONFIG_CRYPTO_LIB_AES_CBC */
static inline void aes_cbc_fips_test(void)
@@ -1194,7 +1194,7 @@ static void __init aes_ctr_fips_test(void)
if (memcmp(fips_test_data, data, sizeof(data)) != 0)
panic("aes: CTR FIPS self-test failed (wrong plaintext)\n");
- memzero_explicit(&key, sizeof(key));
+ aes_zeroize_enckey(&key);
}
#else /* CONFIG_CRYPTO_LIB_AES_CTR */
static inline void aes_ctr_fips_test(void)
--
2.55.0
next prev parent reply other threads:[~2026-09-10 12:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 12:41 [PATCH v3 00/13] libcrypto: Provide more __cleanup functions for zeroizing data Thomas Huth
2026-09-10 12:41 ` Thomas Huth [this message]
2026-09-10 12:41 ` [PATCH v3 02/13] lib/crypto: aes-xts: Provide function for zeroizing aes_xts_key Thomas Huth
2026-09-10 12:41 ` [PATCH v3 03/13] lib/crypto: aes-gcm: Provide functions for zeroizing aes_gcm* structures Thomas Huth
2026-09-10 12:41 ` [PATCH v3 04/13] lib/crypto: aes-ccm: Provide functions for zeroizing aes_ccm* structures Thomas Huth
2026-09-10 12:41 ` [PATCH v3 05/13] lib/crypto: md5: Provide a function for zeroizing hmac_md5 structures Thomas Huth
2026-09-10 12:41 ` [PATCH v3 06/13] lib/crypto: sm3: Provide a function for zeroizing the sm3_ctx structure Thomas Huth
2026-09-10 12:41 ` [PATCH v3 07/13] lib/crypto: blake2: Provide functions for zeroizing blake2*_ctx structures Thomas Huth
2026-09-10 12:41 ` [PATCH v3 08/13] lib/crypto: sha1: Provide functions for zeroizing hmac_sha1 structures Thomas Huth
2026-09-10 12:41 ` [PATCH v3 09/13] security: keys: trusted: always clear the hmac_sha1_ctx before returning Thomas Huth
2026-09-10 12:41 ` [PATCH v3 10/13] x86/purgatory: Compile purgatory.c with -D__NO_FORTIFY Thomas Huth
2026-09-10 12:41 ` [PATCH v3 11/13] lib/crypto: sha2: Provide functions for zeroizing SHA2 hmac_sha* structures Thomas Huth
2026-09-11 1:15 ` Namjae Jeon
2026-09-10 12:41 ` [PATCH v3 12/13] smb: client: Use hmac_sha256_zeroize_ctx function to clear hmac_sha256_ctx Thomas Huth
2026-09-10 12:41 ` [PATCH v3 13/13] lib/crypto: Add documentation about zeroization of key and context data Thomas Huth
2026-09-10 15:09 ` Eric Biggers
2026-09-10 15:40 ` [PATCH v3 00/13] libcrypto: Provide more __cleanup functions for zeroizing data Borislav Petkov
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=20260910124138.417439-2-thuth@redhat.com \
--to=thuth@redhat.com \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@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 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.