From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@kernel.org>
Subject: [PATCH] lib/crypto: aesgcm: Don't disable IRQs during AES block encryption
Date: Mon, 30 Mar 2026 19:44:30 -0700 [thread overview]
Message-ID: <20260331024430.51755-1-ebiggers@kernel.org> (raw)
aes_encrypt() now uses AES instructions when available instead of always
using table-based code. AES instructions are constant-time and don't
benefit from disabling IRQs as a constant-time hardening measure.
In fact, on two architectures (arm and riscv) disabling IRQs is
counterproductive because it prevents the AES instructions from being
used. (See the may_use_simd() implementation on those architectures.)
Therefore, let's remove the IRQ disabling/enabling and leave the choice
of constant-time hardening measures to the AES library code.
Note that currently the arm table-based AES code (which runs on arm
kernels that don't have ARMv8 CE) disables IRQs, while the generic
table-based AES code does not. So this does technically regress in
constant-time hardening when that generic code is used. But as
discussed in commit a22fd0e3c495 ("lib/crypto: aes: Introduce improved
AES library") I think just leaving IRQs enabled is the right choice.
Disabling them is slow and can cause problems, and AES instructions
(which modern CPUs have) solve the problem in a much better way anyway.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
lib/crypto/aesgcm.c | 25 +++----------------------
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/lib/crypto/aesgcm.c b/lib/crypto/aesgcm.c
index 8c7e74d2d147..1da31e1f747d 100644
--- a/lib/crypto/aesgcm.c
+++ b/lib/crypto/aesgcm.c
@@ -7,29 +7,10 @@
#include <crypto/gcm.h>
#include <crypto/utils.h>
#include <linux/export.h>
#include <linux/module.h>
-#include <asm/irqflags.h>
-
-static void aesgcm_encrypt_block(const struct aes_enckey *key, void *dst,
- const void *src)
-{
- unsigned long flags;
-
- /*
- * In AES-GCM, both the GHASH key derivation and the CTR mode
- * encryption operate on known plaintext, making them susceptible to
- * timing attacks on the encryption key. The AES library already
- * mitigates this risk to some extent by pulling the entire S-box into
- * the caches before doing any substitutions, but this strategy is more
- * effective when running with interrupts disabled.
- */
- local_irq_save(flags);
- aes_encrypt(key, dst, src);
- local_irq_restore(flags);
-}
/**
* aesgcm_expandkey - Expands the AES and GHASH keys for the AES-GCM key
* schedule
*
@@ -51,11 +32,11 @@ int aesgcm_expandkey(struct aesgcm_ctx *ctx, const u8 *key,
aes_prepareenckey(&ctx->aes_key, key, keysize);
if (ret)
return ret;
ctx->authsize = authsize;
- aesgcm_encrypt_block(&ctx->aes_key, h, h);
+ aes_encrypt(&ctx->aes_key, h, h);
ghash_preparekey(&ctx->ghash_key, h);
memzero_explicit(h, sizeof(h));
return 0;
}
EXPORT_SYMBOL(aesgcm_expandkey);
@@ -96,11 +77,11 @@ static void aesgcm_mac(const struct aesgcm_ctx *ctx, const u8 *src, int src_len,
ghash_update(&ghash, (const u8 *)&tail, sizeof(tail));
ghash_final(&ghash, ghash_out);
ctr[3] = cpu_to_be32(1);
- aesgcm_encrypt_block(&ctx->aes_key, enc_ctr, ctr);
+ aes_encrypt(&ctx->aes_key, enc_ctr, (const u8 *)ctr);
crypto_xor_cpy(authtag, ghash_out, enc_ctr, ctx->authsize);
memzero_explicit(ghash_out, sizeof(ghash_out));
memzero_explicit(enc_ctr, sizeof(enc_ctr));
}
@@ -118,11 +99,11 @@ static void aesgcm_crypt(const struct aesgcm_ctx *ctx, u8 *dst, const u8 *src,
* inadvertent IV reuse, which must be avoided at all cost for
* stream ciphers such as AES-CTR. Given the range of 'int
* len', this cannot happen, so no explicit test is necessary.
*/
ctr[3] = cpu_to_be32(n++);
- aesgcm_encrypt_block(&ctx->aes_key, buf, ctr);
+ aes_encrypt(&ctx->aes_key, buf, (const u8 *)ctr);
crypto_xor_cpy(dst, src, buf, min(len, AES_BLOCK_SIZE));
dst += AES_BLOCK_SIZE;
src += AES_BLOCK_SIZE;
len -= AES_BLOCK_SIZE;
base-commit: d2a68aba8505ce88b39c34ecb3b707c776af79d4
prerequisite-patch-id: bb75bceea1086ce63912baf959cd010cdd451208
--
2.53.0
next reply other threads:[~2026-03-31 2:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 2:44 Eric Biggers [this message]
2026-03-31 5:02 ` [PATCH] lib/crypto: aesgcm: Don't disable IRQs during AES block encryption Eric Biggers
2026-03-31 7:05 ` Ard Biesheuvel
2026-03-31 20:55 ` Eric Biggers
2026-04-01 20:18 ` Eric Biggers
2026-04-02 23:11 ` 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=20260331024430.51755-1-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.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.