* [PATCH v2 01/19] crypto: talitos/hash - Use CRYPTO_AHASH_BLOCK_ONLY API
From: Paul Louvel @ 2026-06-11 7:35 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Thomas Petazzoni, Herve Codina, Christophe Leroy, linux-crypto,
linux-kernel, Paul Louvel
In-Reply-To: <20260611-7-1-rc1_talitos_cleanup-v2-0-aa4a813ce69b@bootlin.com>
The hash implementation maintained a software buffer to accumulate
partial blocks across update() calls, copying data to/from scatterlists
with sg_copy_to_buffer()/sg_pcopy_to_buffer() and chaining in a virtual
scatterlist entry. This is unnecessary now with
CRYPTO_AHASH_ALG_BLOCK_ONLY flag.
Remove unnecessary fields in the request and export structure. On
completion, pass any remaining tail bytes back via
ahash_request_complete() so that the core re-submits them with the next
request.
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
drivers/crypto/talitos.c | 151 ++++++++++++++++++-----------------------------
1 file changed, 57 insertions(+), 94 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 584508963241..12fb61ee8066 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -935,31 +935,23 @@ struct talitos_ctx {
unsigned int authkeylen;
};
-#define HASH_MAX_BLOCK_SIZE SHA512_BLOCK_SIZE
#define TALITOS_MDEU_MAX_CONTEXT_SIZE TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512
struct talitos_ahash_req_ctx {
u32 hw_context[TALITOS_MDEU_MAX_CONTEXT_SIZE / sizeof(u32)];
unsigned int hw_context_size;
- u8 buf[2][HASH_MAX_BLOCK_SIZE];
- int buf_idx;
unsigned int swinit;
unsigned int first_request;
unsigned int last_request;
unsigned int to_hash_later;
- unsigned int nbuf;
- struct scatterlist bufsl[2];
- struct scatterlist *psrc;
};
struct talitos_export_state {
u32 hw_context[TALITOS_MDEU_MAX_CONTEXT_SIZE / sizeof(u32)];
- u8 buf[HASH_MAX_BLOCK_SIZE];
unsigned int swinit;
unsigned int first_request;
unsigned int last_request;
unsigned int to_hash_later;
- unsigned int nbuf;
};
static int aead_setkey(struct crypto_aead *authenc,
@@ -1826,14 +1818,8 @@ static void ahash_done(struct device *dev,
struct talitos_edesc *next;
if (is_sec1) {
- if (!req_ctx->last_request && req_ctx->to_hash_later) {
- /* Position any partial block for next update/final/finup */
- req_ctx->buf_idx = (req_ctx->buf_idx + 1) & 1;
- req_ctx->nbuf = req_ctx->to_hash_later;
- }
-
free_edesc_list_from(areq, edesc);
- ahash_request_complete(areq, err);
+ ahash_request_complete(areq, err ?: req_ctx->to_hash_later);
} else {
next = edesc->next_desc;
@@ -1851,14 +1837,9 @@ static void ahash_done(struct device *dev,
return;
}
out:
- if (!req_ctx->last_request && req_ctx->to_hash_later) {
- /* Position any partial block for next update/final/finup */
- req_ctx->buf_idx = (req_ctx->buf_idx + 1) & 1;
- req_ctx->nbuf = req_ctx->to_hash_later;
- }
if (err && next)
free_edesc_list_from(areq, next);
- ahash_request_complete(areq, err);
+ ahash_request_complete(areq, err ?: req_ctx->to_hash_later);
}
}
@@ -1978,7 +1959,7 @@ ahash_process_req_prepare(struct ahash_request *areq, unsigned int nbytes,
size_t offset = 0;
do {
- src = scatterwalk_ffwd(tmp, req_ctx->psrc, offset);
+ src = scatterwalk_ffwd(tmp, areq->src, offset);
to_hash_this_desc =
min(nbytes, ALIGN_DOWN(desc_max, blocksize));
@@ -1991,8 +1972,7 @@ ahash_process_req_prepare(struct ahash_request *areq, unsigned int nbytes,
return edesc;
}
- edesc->src =
- scatterwalk_ffwd(edesc->bufsl, req_ctx->psrc, offset);
+ edesc->src = scatterwalk_ffwd(edesc->bufsl, areq->src, offset);
edesc->desc.hdr = ctx->desc_hdr_template;
edesc->first = offset == 0;
edesc->last = nbytes - to_hash_this_desc == 0;
@@ -2045,62 +2025,17 @@ static int ahash_process_req(struct ahash_request *areq, unsigned int nbytes)
bool is_sec1 = has_ftr_sec1(dev_get_drvdata(ctx->dev));
unsigned int nbytes_to_hash;
unsigned int to_hash_later;
- unsigned int nsg;
- int nents;
struct device *dev = ctx->dev;
- u8 *ctx_buf = req_ctx->buf[req_ctx->buf_idx];
int ret;
- if (!req_ctx->last_request && (nbytes + req_ctx->nbuf <= blocksize)) {
- /* Buffer up to one whole block */
- nents = sg_nents_for_len(areq->src, nbytes);
- if (nents < 0) {
- dev_err(dev, "Invalid number of src SG.\n");
- return nents;
- }
- sg_copy_to_buffer(areq->src, nents,
- ctx_buf + req_ctx->nbuf, nbytes);
- req_ctx->nbuf += nbytes;
- return 0;
- }
-
- /* At least (blocksize + 1) bytes are available to hash */
- nbytes_to_hash = nbytes + req_ctx->nbuf;
- to_hash_later = nbytes_to_hash & (blocksize - 1);
+ nbytes_to_hash = ALIGN_DOWN(nbytes, blocksize);
+ to_hash_later = nbytes - nbytes_to_hash;
- if (req_ctx->last_request)
+ if (req_ctx->last_request) {
+ nbytes_to_hash = nbytes;
to_hash_later = 0;
- else if (to_hash_later)
- /* There is a partial block. Hash the full block(s) now */
- nbytes_to_hash -= to_hash_later;
- else {
- /* Keep one block buffered */
- nbytes_to_hash -= blocksize;
- to_hash_later = blocksize;
- }
-
- /* Chain in any previously buffered data */
- if (req_ctx->nbuf) {
- nsg = (req_ctx->nbuf < nbytes_to_hash) ? 2 : 1;
- sg_init_table(req_ctx->bufsl, nsg);
- sg_set_buf(req_ctx->bufsl, ctx_buf, req_ctx->nbuf);
- if (nsg > 1)
- sg_chain(req_ctx->bufsl, 2, areq->src);
- req_ctx->psrc = req_ctx->bufsl;
- } else
- req_ctx->psrc = areq->src;
-
- if (to_hash_later) {
- nents = sg_nents_for_len(areq->src, nbytes);
- if (nents < 0) {
- dev_err(dev, "Invalid number of src SG.\n");
- return nents;
- }
- sg_pcopy_to_buffer(areq->src, nents,
- req_ctx->buf[(req_ctx->buf_idx + 1) & 1],
- to_hash_later,
- nbytes - to_hash_later);
}
+
req_ctx->to_hash_later = to_hash_later;
edesc = ahash_process_req_prepare(areq, nbytes_to_hash, blocksize,
@@ -2125,8 +2060,6 @@ static int ahash_init(struct ahash_request *areq)
dma_addr_t dma;
/* Initialize the context */
- req_ctx->buf_idx = 0;
- req_ctx->nbuf = 0;
req_ctx->first_request = 1;
req_ctx->swinit = 0; /* assume h/w init of context */
size = (crypto_ahash_digestsize(tfm) <= SHA256_DIGEST_SIZE)
@@ -2223,12 +2156,10 @@ static int ahash_export(struct ahash_request *areq, void *out)
memcpy(export->hw_context, req_ctx->hw_context,
req_ctx->hw_context_size);
- memcpy(export->buf, req_ctx->buf[req_ctx->buf_idx], req_ctx->nbuf);
export->swinit = req_ctx->swinit;
export->first_request = req_ctx->first_request;
export->last_request = req_ctx->last_request;
export->to_hash_later = req_ctx->to_hash_later;
- export->nbuf = req_ctx->nbuf;
return 0;
}
@@ -2249,12 +2180,10 @@ static int ahash_import(struct ahash_request *areq, const void *in)
: TALITOS_MDEU_CONTEXT_SIZE_SHA384_SHA512;
req_ctx->hw_context_size = size;
memcpy(req_ctx->hw_context, export->hw_context, size);
- memcpy(req_ctx->buf[0], export->buf, export->nbuf);
req_ctx->swinit = export->swinit;
req_ctx->first_request = export->first_request;
req_ctx->last_request = export->last_request;
req_ctx->to_hash_later = export->to_hash_later;
- req_ctx->nbuf = export->nbuf;
dma = dma_map_single(dev, req_ctx->hw_context, req_ctx->hw_context_size,
DMA_TO_DEVICE);
@@ -2932,8 +2861,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "md5",
.cra_driver_name = "md5-talitos",
.cra_blocksize = MD5_HMAC_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2948,8 +2880,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "sha1",
.cra_driver_name = "sha1-talitos",
.cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2964,8 +2899,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "sha224",
.cra_driver_name = "sha224-talitos",
.cra_blocksize = SHA224_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2980,8 +2918,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "sha256",
.cra_driver_name = "sha256-talitos",
.cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2996,8 +2937,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "sha384",
.cra_driver_name = "sha384-talitos",
.cra_blocksize = SHA384_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3012,8 +2956,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "sha512",
.cra_driver_name = "sha512-talitos",
.cra_blocksize = SHA512_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3028,8 +2975,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(md5)",
.cra_driver_name = "hmac-md5-talitos",
.cra_blocksize = MD5_HMAC_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3044,8 +2994,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(sha1)",
.cra_driver_name = "hmac-sha1-talitos",
.cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3060,8 +3013,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(sha224)",
.cra_driver_name = "hmac-sha224-talitos",
.cra_blocksize = SHA224_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3076,8 +3032,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(sha256)",
.cra_driver_name = "hmac-sha256-talitos",
.cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3092,8 +3051,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(sha384)",
.cra_driver_name = "hmac-sha384-talitos",
.cra_blocksize = SHA384_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3108,8 +3070,11 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "hmac(sha512)",
.cra_driver_name = "hmac-sha512-talitos",
.cra_blocksize = SHA512_BLOCK_SIZE,
+ .cra_reqsize = sizeof(struct talitos_ahash_req_ctx),
.cra_flags = CRYPTO_ALG_ASYNC |
- CRYPTO_ALG_ALLOCATES_MEMORY,
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_AHASH_ALG_BLOCK_ONLY |
+ CRYPTO_AHASH_ALG_FINAL_NONZERO,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -3181,8 +3146,6 @@ static int talitos_cra_init_ahash(struct crypto_tfm *tfm)
algt.alg.hash);
ctx->keylen = 0;
- crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
- sizeof(struct talitos_ahash_req_ctx));
return talitos_init_common(ctx, talitos_alg);
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 00/19] crypto: talitos - Driver cleanup
From: Paul Louvel @ 2026-06-11 7:35 UTC (permalink / raw)
To: Herbert Xu, David S. Miller
Cc: Thomas Petazzoni, Herve Codina, Christophe Leroy, linux-crypto,
linux-kernel, Paul Louvel
The Freescale Integrated Security Engine (SEC) aka "Talitos" driver
implementation is a monolithic ~3800-line file that mixes SEC1 and SEC2
hardware variants with hash, skcipher, aead and hwrng algorithm.
This series reorganises the driver to improve readability and
maintainability:
- Split the driver into a dedicated directory with separate files for
hash, skcipher, aead, and hwrng implementations.
- Modernise the crypto API usage: adopt {init,exit}_tfm (deprecated
cra_init/cra_exit), use CRYPTO_AHASH_ALG_BLOCK_ONLY to eliminate
manual partial-block buffering, and use macros to deduplicate
algorithm definitions.
- Introduce a is_sec1() helper to get rid of is_sec1 variables /
parameters.
- Define descriptor/pointer structures for each hardware version,
instead of using a single structure and anonymous union.
No functional changes are intended except for patch 1.
This series depends on the "crypto: talitos - bug fixes" series :
https://patch.msgid.link/20260507-bootlin_test-7-1-rc1_sec_bugfix-v3-0-c98d7589b942@bootlin.com
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
---
Changes in v2:
- Fixed compilation warnings and errors.
- Instead of using ops to dispatch SEC1/SEC2 variants, keep the small
helpers, and introduce is_sec1() inline function that can use static
key branching in case both hardware version are compiled.
- Dropped the SEC1/SEC2 function variants inside the core driver file.
- Reworded the cover letter for clarity.
- Link to v1: https://patch.msgid.link/20260528-7-1-rc1_talitos_cleanup-v1-0-cb1ad6cdea49@bootlin.com
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Paul Louvel (19):
crypto: talitos/hash - Use CRYPTO_AHASH_BLOCK_ONLY API
crypto: talitos - Move driver into dedicated directory
crypto: talitos - Add missing includes to driver header file
crypto: talitos/hwrng - Move into separate file
crypto: talitos - Prepare crypto implementation file splitting
crypto: talitos/hash - Move into separate file
crypto: talitos/skcipher - Move into separate file
crypto: talitos/aead - Move into separate file
crypto: talitos/hash - Convert to {init,exit}_tfm type-specific API
crypto: talitos/skcipher - Convert to {init,exit}_tfm type-specific API
crypto: talitos/aead - Convert to {init,exit}_tfm type-specific API
crypto: talitos/hash - Use macro for algorithm definitions
crypto: talitos/skcipher - Use macro for algorithm definitions
crypto: talitos/aead - Use macro for algorithm definitions
crypto: talitos - Remove alg settings in talitos_register_common()
crypto: talitos - Introduce is_sec1() helper with static key support
crypto: talitos - Replace has_ftr_sec1() with is_sec1() static key helper
crypto: talitos - Introduce per-SEC-version descriptor and pointer structures
crypto: talitos - Remove TALITOS_DESC_SIZE macro
drivers/crypto/Kconfig | 38 +-
drivers/crypto/Makefile | 2 +-
drivers/crypto/talitos.c | 3640 -----------------------------
drivers/crypto/talitos/Kconfig | 36 +
drivers/crypto/talitos/Makefile | 3 +
drivers/crypto/talitos/talitos-aead.c | 657 ++++++
drivers/crypto/talitos/talitos-hash.c | 691 ++++++
drivers/crypto/talitos/talitos-rng.c | 93 +
drivers/crypto/talitos/talitos-skcipher.c | 356 +++
drivers/crypto/talitos/talitos.c | 1337 +++++++++++
drivers/crypto/{ => talitos}/talitos.h | 316 ++-
11 files changed, 3463 insertions(+), 3706 deletions(-)
---
base-commit: db8b9f227833e729faf44a512aa1e88a625b5ad8
change-id: 20260518-7-1-rc1_talitos_cleanup-9231a64e29fa
prerequisite-change-id: 20260504-bootlin_test-7-1-rc1_sec_bugfix-13169ed07ddc:v3
prerequisite-patch-id: 7b364911e4b8d1c1033eb14e67ed24dac6a4bc13
prerequisite-patch-id: 2c1cd7fdd003d9a116a697efa25d1716d548389f
prerequisite-patch-id: b12bdbf565747609e0cfe0609a42cf69b5d816a1
prerequisite-patch-id: 72cb2bc0fc2a48a5a029b049c199f4c86085cf04
prerequisite-patch-id: 5f1f5ad6add760161bd48875df48c0893aa12613
prerequisite-patch-id: 934931086968229434d15a2f2358aeb7e6975a1d
prerequisite-patch-id: 8a0b4828fc0690e0c841bc9adcc6568bb522e0e8
prerequisite-patch-id: 1d870f32e7dbf9a8bd3b8979558544107693e0f4
prerequisite-patch-id: 758c18d7c9fabb14bd90df62e5e8a62a6f880db4
prerequisite-patch-id: ce6e9e585f8edc1861ae6bb8fbdd836c20cbd290
prerequisite-patch-id: 9446dc03e442ea81c5f5b39e802e01b37da29971
Best regards,
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Michael S. Tsirkin @ 2026-06-11 7:30 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael Bommarito, Olivia Mackall, linux-crypto, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <aio83ZWadVTiuNpR@gondor.apana.org.au>
On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> >
> > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > + memcpy(buf, vi->data + idx, size);
>
> I don't see how nospec can help here. Please enlighten me.
All the "malicious device" things are confusing. Spectre things -
doubly so.
So if an access is speculated then CPU might speculate feeding a kernel
secret into RNG. And then the speculated RNG value maybe can be also
speculatively be used by some kernel code as an index
to trigger a cache access, finally leaking the secret?
Maybe?
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: exynos-rng - Remove exynos-rng driver
From: Peter Griffin @ 2026-06-11 7:11 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Herbert Xu, linux-samsung-soc, Krzysztof Kozlowski,
Alim Akhtar, linux-kernel
In-Reply-To: <20260610183902.GA1158828@google.com>
Hi Eric,
On Wed, 10 Jun 2026 at 19:39, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, Jun 10, 2026 at 03:46:54PM +0100, Peter Griffin wrote:
> > Hi Eric,
> >
> > On Sun, 31 May 2026 at 19:02, Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > This driver has no purpose. It doesn't feed into the Linux RNG, nor
> > > does it implement the hwrng interface. It is accessible only via the
> > > "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
> > > uses either the Linux RNG, or rarely /dev/hwrng.
> > >
> > > Moreover, this is a PRNG whose only source of entropy is the 160-bit
> > > seed the user passes in. So this can be used only by a user who already
> > > has a source of cryptographically secure random numbers, such as
> > > /dev/random. Which they can, and do, just use in the first place.
> > >
> > > Just remove this driver. There's no need to keep useless code around.
> > >
> > > Note that the other crypto_rng drivers in drivers/crypto/ are similarly
> > > unused and are being removed too. This commit just handles exynos-rng.
> > >
> > > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > > ---
> >
> > If the driver is being removed, should the binding documentation for
> > this driver not also be deleted (see
> > Documentation/devicetree/bindings/rng/samsung,exynos4-rng.yaml)?
> >
> > Peter
>
> In other discussions I've been told that devicetree bindings are
> hardware descriptions that should still exist even if there is no
> driver. It doesn't make a lot of sense, but it seems to be what the
> devicetree people want. I expect there would be objections to removing
> this binding.
Ok thanks for confirming.
Peter.
^ permalink raw reply
* Re: [PATCH v13 2/4] crypto: spacc - Add SPAcc ahash support
From: Herbert Xu @ 2026-06-11 5:50 UTC (permalink / raw)
To: Pavitrakumar Managutte
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, rbannerm, manjunath.hadli, adityak, navami.telsang,
bhoomikak
In-Reply-To: <20260604165210.1141842-3-pavitrakumarm@vayavyalabs.com>
On Thu, Jun 04, 2026 at 10:22:08PM +0530, Pavitrakumar Managutte wrote:
> Add ahash support to SPAcc driver.
> Below are the hash algos supported:
> - cmac(aes)
> - xcbc(aes)
> - cmac(sm4)
> - xcbc(sm4)
> - hmac(md5)
> - md5
> - hmac(sha1)
> - sha1
> - sha224
> - sha256
> - sha384
> - sha512
> - hmac(sha224)
> - hmac(sha256)
> - hmac(sha384)
> - hmac(sha512)
> - sha3-224
> - sha3-256
> - sha3-384
> - sha3-512
> - michael_mic
>
> Co-developed-by: Bhoomika Kadabi <bhoomikak@vayavyalabs.com>
> Signed-off-by: Bhoomika Kadabi <bhoomikak@vayavyalabs.com>
> Acked-by: Ross Bannerman <rbannerm@synopsys.com>
> Signed-off-by: Pavitrakumar Managutte <pavitrakumarm@vayavyalabs.com>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@vayavyalabs.com>
> ---
> drivers/crypto/dwc-spacc/spacc_ahash.c | 897 ++++++++++++++
> drivers/crypto/dwc-spacc/spacc_core.c | 1311 ++++++++++++++++++++
> drivers/crypto/dwc-spacc/spacc_core.h | 838 +++++++++++++
> drivers/crypto/dwc-spacc/spacc_device.c | 275 ++++
> drivers/crypto/dwc-spacc/spacc_device.h | 237 ++++
> drivers/crypto/dwc-spacc/spacc_hal.c | 374 ++++++
> drivers/crypto/dwc-spacc/spacc_hal.h | 114 ++
> drivers/crypto/dwc-spacc/spacc_interrupt.c | 329 +++++
> drivers/crypto/dwc-spacc/spacc_manager.c | 611 +++++++++
> 9 files changed, 4986 insertions(+)
> create mode 100644 drivers/crypto/dwc-spacc/spacc_ahash.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_core.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_core.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_device.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_device.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_hal.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_hal.h
> create mode 100644 drivers/crypto/dwc-spacc/spacc_interrupt.c
> create mode 100644 drivers/crypto/dwc-spacc/spacc_manager.c
Please also check the Sashiko comments, some of those look alarming:
https://sashiko.dev/#/patchset/20260604165210.1141842-1-pavitrakumarm%40vayavyalabs.com
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v13 2/4] crypto: spacc - Add SPAcc ahash support
From: Herbert Xu @ 2026-06-11 5:49 UTC (permalink / raw)
To: Pavitrakumar Managutte
Cc: linux-crypto, linux-kernel, devicetree, robh, conor+dt,
Ruud.Derwig, rbannerm, manjunath.hadli, adityak, navami.telsang,
bhoomikak
In-Reply-To: <20260604165210.1141842-3-pavitrakumarm@vayavyalabs.com>
On Thu, Jun 04, 2026 at 10:22:08PM +0530, Pavitrakumar Managutte wrote:
>
> +static int spacc_hash_do_one_request(struct crypto_engine *engine, void *areq)
> +{
> + struct ahash_request *req = ahash_request_cast(areq);
> + struct crypto_ahash *reqtfm = crypto_ahash_reqtfm(req);
> + struct spacc_crypto_ctx *tctx = crypto_ahash_ctx(reqtfm);
> + struct spacc_crypto_reqctx *ctx = ahash_request_ctx(req);
> + struct spacc_priv *priv = dev_get_drvdata(tctx->dev);
> + const struct spacc_alg *salg = spacc_tfm_ahash(&reqtfm->base);
> + int rc = 0;
> +
> + ctx->single_shot = 1;
> + ctx->total_nents = sg_nents(req->src);
> +
> + tctx->tmp_sgl = kmalloc_array(2, sizeof(*tctx->tmp_sgl), GFP_KERNEL);
> +
> + if (!tctx->tmp_sgl)
> + goto fallback;
> +
> + sg_init_table(tctx->tmp_sgl, 2);
> + tctx->tmp_sgl[0].length = 0;
> +
> + if (tctx->handle < 0 || !tctx->ctx_valid) {
> + priv = dev_get_drvdata(salg->dev);
> + tctx->dev = get_device(salg->dev);
> +
> + rc = spacc_is_mode_keysize_supported(&priv->spacc,
> + salg->mode->id, tctx->keylen, 1);
This check could've been done before going through the crypto
engine. If we're just going to use the fallback, there is no
point going all the way through the engine just to drop out right
at the end.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: chelsio: fix refcount leaks in ahash request functions
From: Herbert Xu @ 2026-06-11 5:41 UTC (permalink / raw)
To: Wentao Liang; +Cc: ayush.sawal, davem, linux-crypto, linux-kernel, stable
In-Reply-To: <20260604101308.3785365-1-vulab@iscas.ac.cn>
On Thu, Jun 04, 2026 at 10:13:08AM +0000, Wentao Liang wrote:
> When chcr_send_wr() fails in chcr_ahash_finup(), chcr_ahash_final(),
> chcr_ahash_update(), or chcr_ahash_digest(), the function still returns
> -EINPROGRESS to the crypto layer, claiming the request has been
> submitted. No completion callback will be triggered because the work
> request was not actually handed over to the hardware, so the
> dev->inflight refcount that was incremented by chcr_inc_wrcount() is
> never decremented. This permanently prevents device detach and leads
> to a resource leak.
>
> Check the return value of chcr_send_wr() and jump to the error unmap
> path on failure so that the refcount is properly undone before
> returning an error.
>
> Cc: stable@vger.kernel.org
> Fixes: 324429d74127 ("chcr: Support for Chelsio's Crypto Hardware")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> drivers/crypto/chelsio/chcr_algo.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
> index 14a708defcd4..142eccaf82fe 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -1877,7 +1877,10 @@ static int chcr_ahash_finup(struct ahash_request *req)
> req_ctx->hctx_wr.processed += params.sg_len;
> skb->dev = u_ctx->lldi.ports[0];
> set_wr_txq(skb, CPL_PRIORITY_DATA, req_ctx->txqidx);
> - chcr_send_wr(skb);
> + if (chcr_send_wr(skb)) {
> + error = -EIO;
> + goto unmap;
> + }
This call is made half a dozen times in this file so fixing one
of them is not going to make much of a difference. Either fix them
all or just mark this driver as broken.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: omap - use min3 to simplify omap_crypto_copy_data
From: Herbert Xu @ 2026-06-11 5:37 UTC (permalink / raw)
To: Thorsten Blum; +Cc: David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260604001035.1256238-3-thorsten.blum@linux.dev>
On Thu, Jun 04, 2026 at 02:10:36AM +0200, Thorsten Blum wrote:
> Replace two consecutive min() calls with min3() to simplify the code.
>
> Change the function parameters and local variables from int to size_t
> since these represent unsigned values and to prevent a signedness error.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/omap-crypto.c | 12 ++++++------
> drivers/crypto/omap-crypto.h | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
Please stop these min3 patches. It makes the code harder to read
for humans.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: atmel-ecc - remove stale comments in atmel_ecc_remove
From: Herbert Xu @ 2026-06-11 5:29 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260602165247.977197-3-thorsten.blum@linux.dev>
On Tue, Jun 02, 2026 at 06:52:49PM +0200, Thorsten Blum wrote:
> atmel_ecc_remove() no longer returns -EBUSY since commit 7df7563b16aa
> ("crypto: atmel-ecc - Remove duplicated error reporting in .remove()")
> and is a void function since commit ed5c2f5fd10d ("i2c: Make remove
> callback return void").
>
> Remove and update the outdated comments.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-ecc.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
> index 9c380351d2f9..e6068dc0a0c1 100644
> --- a/drivers/crypto/atmel-ecc.c
> +++ b/drivers/crypto/atmel-ecc.c
> @@ -347,13 +347,11 @@ static void atmel_ecc_remove(struct i2c_client *client)
> {
> struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
>
> - /* Return EBUSY if i2c client already allocated. */
> if (atomic_read(&i2c_priv->tfm_count)) {
> /*
> * After we return here, the memory backing the device is freed.
> - * That happens no matter what the return value of this function
> - * is because in the Linux device model there is no error
> - * handling for unbinding a driver.
> + * That happens because in the Linux device model there is no
> + * error handling for unbinding a driver.
> * If there is still some action pending, it probably involves
> * accessing the freed memory.
> */
Please fix this properly rather than fiddling with the comments.
Drivers should always fail gracefully if the hardware disappears.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: algif_skcipher - snapshot IV for async skcipher requests
From: Herbert Xu @ 2026-06-11 5:19 UTC (permalink / raw)
To: Max Clinton; +Cc: linux-crypto, linux-kernel, gregkh, davem, security, stable
In-Reply-To: <20260601192927.1095129-1-maxtclinton@gmail.com>
On Mon, Jun 01, 2026 at 03:29:27PM -0400, Max Clinton wrote:
> AF_ALG skcipher AIO requests currently use the socket-wide IV buffer
> during request processing. For async requests, later socket activity
> can update that shared state before the original request has fully
> completed, which can lead to inconsistent IV handling.
>
> Snapshot the IV into per-request storage when preparing the skcipher
> request, so in-flight operations no longer depend on mutable socket
> state.
>
> This mirrors the algif_aead fix from commit 5aa58c3a572b ("crypto:
> algif_aead - snapshot IV for async AEAD requests"), which addressed
> the same shape of bug in the AEAD sibling subsystem.
>
> Tested on Debian Trixie 6.12.74+deb13+1-amd64 (unpatched) and on
> v6.12.86 + this patch via virtme-ng on the same host. Reproducer
> results: 10-14% race rate over 50000 iterations on the unpatched
> kernel against cryptd(cbc(aes-generic)); 0 races at 50000 and
> 200000 iterations on the patched kernel; 0 races at 200000
> iterations on the unpatched kernel with the synchronous
> cbc(aes-generic) driver as a control case (confirming the race is
> gated on the async dispatch path).
>
> Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management")
> Cc: stable@kernel.org
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Max Clinton <maxtclinton@gmail.com>
> ---
> Changes since v1:
> - Drop unneeded <crypto/internal/skcipher.h> include (Herbert).
> - Rewrite iv pointer computation as (areq + 1) + reqsize per
> Herbert's suggestion.
>
> crypto/algif_skcipher.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Given that AIO support has just been removed this patch is no
longer necessary:
commit fcc77d33a34cf271702e8daafb6c593e4626776d
Author: Demi Marie Obenour <demiobenour@gmail.com>
Date: Sat May 23 15:43:02 2026 -0400
net: Remove support for AIO on sockets
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] hwrng: core - Do not read data during PM sleep transition
From: Herbert Xu @ 2026-06-11 5:16 UTC (permalink / raw)
To: Thomas Richard (TI)
Cc: Olivia Mackall, Thomas Petazzoni, linux-crypto, linux-kernel,
gregory.clement, richard.genoud, u-kumar1, a-kumar2
In-Reply-To: <20260601-hw-random-fix-hwrng-fillfn-crash-suspend-resume-v2-1-667ce5da32ee@bootlin.com>
On Mon, Jun 01, 2026 at 03:19:13PM +0200, Thomas Richard (TI) wrote:
>
> @@ -538,8 +539,9 @@ static int hwrng_fillfn(void *unused)
> }
>
> mutex_lock(&reading_mutex);
> - rc = rng_get_data(rng, rng_fillbuf,
> - rng_buffer_size(), 1);
> + if (!pm_sleep_transition_in_progress())
> + rc = rng_get_data(rng, rng_fillbuf,
> + rng_buffer_size(), 1);
Sashiko asks how this can be safe given that there is no locking
at all. That's exactly what I was going to ask :)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 1/4] crypto: skcipher - add per-tfm data_unit_size for batched requests
From: Herbert Xu @ 2026-06-11 5:07 UTC (permalink / raw)
To: Leonid Ravich
Cc: Alasdair Kergon, Ard Biesheuvel, Eric Biggers, Jens Axboe,
Horia Geanta, Gilad Ben-Yossef, linux-crypto, dm-devel,
linux-block
In-Reply-To: <20260601085644.13026-2-lravich@amazon.com>
On Mon, Jun 01, 2026 at 08:56:41AM +0000, Leonid Ravich wrote:
>
> diff --git a/crypto/skcipher.c b/crypto/skcipher.c
> index 2b31d1d5d268..bc37bd554aec 100644
> --- a/crypto/skcipher.c
> +++ b/crypto/skcipher.c
> @@ -432,13 +432,119 @@ int crypto_skcipher_setkey(struct crypto_skcipher *tfm, const u8 *key,
> }
> EXPORT_SYMBOL_GPL(crypto_skcipher_setkey);
>
> +int crypto_skcipher_set_data_unit_size(struct crypto_skcipher *tfm,
> + unsigned int data_unit_size)
> +{
> + unsigned int blocksize;
> +
> + if (!data_unit_size) {
> + tfm->data_unit_size = 0;
> + return 0;
> + }
> +
> + if (!crypto_skcipher_supports_multi_data_unit(tfm))
> + return -EOPNOTSUPP;
> +
> + blocksize = crypto_skcipher_blocksize(tfm);
> + if (data_unit_size < blocksize || data_unit_size % blocksize)
> + return -EINVAL;
> +
> + tfm->data_unit_size = data_unit_size;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(crypto_skcipher_set_data_unit_size);
The unit size should be a per-request attribute, not per tfm.
> @@ -492,6 +517,66 @@ static inline unsigned int crypto_lskcipher_chunksize(
> return crypto_lskcipher_alg(tfm)->co.chunksize;
> }
>
> +/**
> + * crypto_skcipher_supports_multi_data_unit() - test multi-data-unit support
> + * @tfm: cipher handle
> + *
> + * Return: true if the algorithm advertises that it can process multiple
> + * data units in a single skcipher_request.
> + */
> +static inline bool
> +crypto_skcipher_supports_multi_data_unit(struct crypto_skcipher *tfm)
> +{
> + return crypto_skcipher_alg_common(tfm)->base.cra_flags &
> + CRYPTO_ALG_SKCIPHER_MULTI_DATA_UNIT;
> +}
My preference is to always use multi-unit submission if the user
is capable of doing it. The Crypto API should automatically divide
up the units if the underlying driver does not support it.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: atmel-tdes - use scatterlist length before DMA mapping
From: Herbert Xu @ 2026-06-11 5:04 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Nicolas Royer, Eric Bénard, stable, linux-crypto,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260531204115.689052-3-thorsten.blum@linux.dev>
On Sun, May 31, 2026 at 10:41:17PM +0200, Thorsten Blum wrote:
> Using sg_dma_len() is only valid after mapping the scatterlist with
> dma_map_sg(). However, atmel_tdes_crypt_start() uses it before mapping
> to compare input/output lengths and to compute the transfer count.
>
> Use the original scatterlist lengths before DMA mapping to avoid reading
> stale or uninitialized DMA lengths when CONFIG_NEED_SG_DMA_LENGTH=y.
>
> Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver")
> Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-tdes.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
> index 643e507f9c02..0d62b24e9fc7 100644
> --- a/drivers/crypto/atmel-tdes.c
> +++ b/drivers/crypto/atmel-tdes.c
> @@ -463,14 +463,14 @@ static int atmel_tdes_crypt_start(struct atmel_tdes_dev *dd)
> IS_ALIGNED(dd->out_sg->length, dd->ctx->block_size);
> fast = in && out;
>
> - if (sg_dma_len(dd->in_sg) != sg_dma_len(dd->out_sg))
> + if (dd->in_sg->length != dd->out_sg->length)
> fast = 0;
> }
>
>
> if (fast) {
> - count = min_t(size_t, dd->total, sg_dma_len(dd->in_sg));
> - count = min_t(size_t, count, sg_dma_len(dd->out_sg));
> + count = min_t(size_t, dd->total, dd->in_sg->length);
> + count = min_t(size_t, count, dd->out_sg->length);
If fast == 1, then dd->in_sg->length must be equal to dd->out_sg->length,
so the second line is redundant.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH RESEND v2 1/1] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Herbert Xu @ 2026-06-11 4:58 UTC (permalink / raw)
To: Lothar Rubusch
Cc: thorsten.blum, davem, nicolas.ferre, alexandre.belloni,
claudiu.beznea, ardb, krzk+dt, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260609094723.47237-1-l.rubusch@gmail.com>
On Tue, Jun 09, 2026 at 09:47:23AM +0000, Lothar Rubusch wrote:
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 4c9af737b33a..20cd915ea8a3 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -31,10 +31,15 @@ static void atmel_sha204a_rng_done(struct atmel_i2c_work_data *work_data,
> struct atmel_i2c_client_priv *i2c_priv = work_data->ctx;
> struct hwrng *rng = areq;
>
> - if (status)
> + if (status) {
> dev_warn_ratelimited(&i2c_priv->client->dev,
> "i2c transaction failed (%d)\n",
> status);
> + kfree(work_data);
> + rng->priv = 0;
Why is this necessary? It appears that rng_read_nonblocking already
zeroes rng->priv.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] hwrng: virtio: clamp device-reported used.len at copy_data()
From: Herbert Xu @ 2026-06-11 4:43 UTC (permalink / raw)
To: Michael Bommarito
Cc: Olivia Mackall, linux-crypto, Michael S . Tsirkin, Jason Wang,
Kees Cook, Christian Borntraeger, virtualization, linux-kernel,
Dan Williams, Ingo Molnar, H. Peter Anvin, torvalds, alan, tglx
In-Reply-To: <20260531142251.2792061-1-michael.bommarito@gmail.com>
On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
>
> + size = min_t(unsigned int, size, avail - vi->data_idx);
> + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> + memcpy(buf, vi->data + idx, size);
I don't see how nospec can help here. Please enlighten me.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: [PATCH 0/4] Xilinx TRNG fix and simplification
From: Jain, Harsh (AECG-SSW) @ 2026-06-11 2:52 UTC (permalink / raw)
To: Eric Biggers, linux-crypto@vger.kernel.org, Herbert Xu
Cc: linux-kernel@vger.kernel.org, Botcha, Mounika, Olivia Mackall,
Simek, Michal, linux-arm-kernel@lists.infradead.org,
Savitala, Sarat Chand, Dhanawade, Mohan
In-Reply-To: <20260531191738.55843-1-ebiggers@kernel.org>
AMD General
Acked-by: Harsh Jain <h.jain@amd.com>
> -----Original Message-----
> From: Eric Biggers <ebiggers@kernel.org>
> Sent: Monday, June 1, 2026 12:48 AM
> To: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>
> Cc: linux-kernel@vger.kernel.org; Botcha, Mounika <Mounika.Botcha@amd.com>;
> Jain, Harsh (AECG-SSW) <h.jain@amd.com>; Olivia Mackall
> <olivia@selenic.com>; Simek, Michal <michal.simek@amd.com>; linux-arm-
> kernel@lists.infradead.org; Eric Biggers <ebiggers@kernel.org>
> Subject: [PATCH 0/4] Xilinx TRNG fix and simplification
>
>
>
> This series fixes and greatly simplifies the Xilinx TRNG driver by:
>
> - Removing the gratuitous crypto_rng interface, leaving just hwrng which
> is the one that actually matters.
>
> - Replacing the really complicated AES based entropy extraction
> algorithm with a much simpler one.
>
> Note that this mirrors similar changes in other drivers.
>
> Eric Biggers (4):
> crypto: xilinx-trng - Remove crypto_rng interface
> crypto: xilinx-trng - Fix return value of xtrng_hwrng_trng_read()
> crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512
> hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/
>
> MAINTAINERS | 2 +-
> arch/arm64/configs/defconfig | 2 +-
> crypto/Kconfig | 5 -
> crypto/Makefile | 2 -
> crypto/df_sp80090a.c | 222 ------------------
> drivers/char/hw_random/Kconfig | 11 +
> drivers/char/hw_random/Makefile | 1 +
> .../xilinx => char/hw_random}/xilinx-trng.c | 134 ++---------
> drivers/crypto/Kconfig | 13 -
> drivers/crypto/xilinx/Makefile | 1 -
> include/crypto/df_sp80090a.h | 53 -----
> 11 files changed, 37 insertions(+), 409 deletions(-)
> delete mode 100644 crypto/df_sp80090a.c
> rename drivers/{crypto/xilinx => char/hw_random}/xilinx-trng.c (75%)
> delete mode 100644 include/crypto/df_sp80090a.h
>
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> prerequisite-patch-id: 07e982b663ac3f8312ca524f6b91b5b38661df5e
> prerequisite-patch-id: 72064361a8f36e015ab0b7e1fa4d364b40d90506
> prerequisite-patch-id: 8978b8e0db7f47935e5f6f0aff14a97f55d3073c
> prerequisite-patch-id: 6aa0e3e93a008279d71e535a3d0cf48643f55e19
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH bpf-next v8 0/4] Add cryptographic hash and signature verification kfuncs to BPF
From: Felix Maurer @ 2026-06-10 19:17 UTC (permalink / raw)
To: Daniel Hodges
Cc: Daniel Hodges, bpf, linux-crypto, linux-kernel, linux-kselftest,
ast, andrii, daniel, vadim.fedorenko, song, yatsenko, martin.lau,
eddyz87, haoluo, jolsa, john.fastabend, kpsingh, sdf,
yonghong.song, herbert, davem
In-Reply-To: <fm43bx7min3olvz4ok46emxvyvbczw4weq5dkwitzwmq6h4jzg@a56b3irxynks>
Hi Daniel,
Sorry for taking long to get back to you, I've been on vacation for a
while.
> It would also be helpful to hear about what your use case is.
I'll put this one first, as it probably informs my thinking quite a bit.
My use case is accessing hash functions from the networking bpf hooks,
mostly XDP and tc. I'm less interested in the cryptographic hash
functions (although I think we should support them as well), but
checksums like CRC32c which have efficient implementations in the kernel
and are not straightforward to implement in bpf.
> > Taking an initial look at your hashing patches, I'm wondering: the usual
> > interface to hash/digest algorithms is to have three functions: an
> > init() function to set up state
>
> Doesn't bpf_crypto_ctx_create already provide the initialization? I was
> trying to make that pattern work by adding the bpf_crypto_type_id to
> make the code a little more maintainable.
No, bpf_crypto_ctx_create() doesn't do the initialization I was
referring to, it only creates the tfm that is later used to do the
hashing. The actual init() of the hash function happens inside
crypto_shash_digest(). More details at the end of my reply.
> > an update() function that can be called multiple times to hash new
> > bytes, and a finalize() function that creates the actual hash.
> > Depending on the algorithm, some of them (esp. finalize) may be
> > no-ops. Often, a fourth function, like hash(), is provided
>
> I think the bpf_crypto_encrypt should cover that along with the
> bpf_crypto_hash in the first patch.
Not sure if I understand you correctly, bpf_crypto_encrypt() shouldn't
be callable for a hashing crypto context at all?
> > I think we should provide the same init/update/finalize interface in bpf
> > as well to make the API more flexible. That would require splitting out
> > the shash_desc from the (mostly static) context. But doing so would also
> > address the review comment from bpf-ci bot to patch 1. WDYT?
>
> I was trying to make things work with the existing bpf_crypto_ctx
> lifecycle. IIRC in the V1/V2 of the series there was a separate struct
> but it was suggested to integrate the changes into bpf_crypto_ctx.
Yes, I see that the idea is to integrate into the existing life cycle
and I appreciate that! But IIUC, they are subtly different at the
moment. Just to be sure, the idea of your first two patches is to
provide an interface to shash that supports the do-all-at-once function
hash()/digest() (i.e., internally do init+update+finalize), pretty much
the equivalent of the existing encrypt() + decrypt() interface to
skcipher, right? I.e. not supporting each and every use case for now but
just the case where all data is available and we want to hash/encrypt/
decrypt in one go?
With that assumption, the current implementation for skcipher looks like
this: we have bpf_crypto_ctx_create(). It sets up a bpf_crypto_ctx with
the chosen algorithm, the right key, etc. It must be called from a
sleepable bpf program because it may require to load the kernel module
with the requested algorithm. The prepared bpf_crypto_ctx can be stored
in a map so it can be used from other (non-sleepable) bpf programs,
e.g., XDP programs.
When the bpf_crypto_ctx is used with encrypt()/decrypt(), both functions
have the siv argument. It's a dynptr to some memory, containing the IV
for algorithms that need it, but also has room for the *state* if the
algorithm needs it. This means, the state is provided (fresh) for each
invocation of encrypt/decrypt.
Your proposed implementation for shash, bpf_crypto_ctx_create() calls
bpf_crypto_shash_alloc_tfm() which creates the tfm (just as above, needs
to be in a sleepable bpf program to potentially load modules), but it
also allocates the shash_desc which has room for some algorithm state if
needed. This mixes the static, long-living, reusable tfm with the
per-invocation shash_desc. shash is safe to use with the same tfm
concurrently exactly because the state is stored in the shash_desc,
which must not be used concurrently. Think of the shash_desc to be the
equivalent of the siv for skcipher.
Therefore, I think the memory for shash_desc.__ctx should come from a
dynptr as well. Do you agree or did I miss something?
Btw, your bpf_crypto_shash_alloc_tfm() never sets shash_desc.__ctx, so
that's a bug anyways.
> Regarding the bpf-ci bot I think it's somewhat valid, but you could
> solve that by putting the bpf_crypto_ctx in a per CPU map or protecting
> it with a bpf spinlock.
Two things for that: for networking use cases, needing a lock because of
implementation details doesn't sound very intriguing. Plus, if per-cpu
or a lock are required, that's currently not enforced. This means an
invalid/unsafe bpf program could pass the verifier, right?
> If you want to give it a go feel free.
If you're still interested in pursuing this, please go ahead with your
work, I don't want to take it from you. Only if you're explicitly not
interested anymore, I'll go ahead and try to build something on top of
you work. Just let me know :)
Thanks,
Felix
^ permalink raw reply
* Re: [PATCH 2/2] crypto: qce: Fix CTR-AES for partial block requests
From: Eric Biggers @ 2026-06-10 18:46 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610-qce_selftest_fix-v1-2-1b0504783a46@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 11:24:05AM +0530, Kuldeep Singh wrote:
> In CTR mode, the IV acts as the initial counter block.
> APer NIST SP 800-38A, after a CTR mode operation the next unused counter
> value is:
>
> IV_next = IV_in + ceil(cryptlen / AES_BLOCK_SIZE)
>
> The skcipher requires req->iv to hold this updated counter on
> completion, ensuring chained requests produce correct results.
>
> Referring to Crypto6.0 documentation, Section 2.2.5 says:
> "The count value increments automatically once per block of data (in
> AES, a block is 16 bytes) based on the value in the
> CRYPTO_ENCR_CNTR_MASK registers."
>
> QCE increments internal counter register once per full 16-byte block(for
> ctr-aes) is processed. In case of partial request length, the hardware
> uses the current counter to generate keystreams but does not increment
> the counter register afterwards. So the counter value written in
> CRYPTO_ENCR_CNTRn_IVn later once read by software is one less than the
> expected value.
>
> Crypto selftest framework capture this scenario with test vector
> 4 comprising of a 499-byte payload (31 full blocks + 3 partial bytes).
> Error:
> [ 5.606169] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
> [ 5.606176] 00000000: e7 82 1d b8 53 11 ac 47 e2 7d 18 d6 71 0c a7 61
> [ 5.606192] alg: self-tests for ctr(aes) using ctr-aes-qce failed (rc=-22)
> Expected iv_out: 0x62 (iv_in + 32)
> Obtained iv_out: 0x61 (iv_in + 31, partial block not counted)
>
> To fix this, just increase the counter value for partial block requests
> by 1 and for the full block size requests, don't take any action as
> expected value is already returned by the hardware.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
This fix isn't Cc'ed to stable, so stable kernels will remain vulnerable
to this bug.
- Eric
^ permalink raw reply
* Re: [PATCH 0/2] Fix Qualcomm Crypto engine self tests failures
From: Eric Biggers @ 2026-06-10 18:42 UTC (permalink / raw)
To: Kuldeep Singh
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Bartosz Golaszewski,
Thara Gopinath, linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260610-qce_selftest_fix-v1-0-1b0504783a46@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 11:24:03AM +0530, Kuldeep Singh wrote:
> Steps followed:
> - Enable EXPERT and CRYPTO_SEFLTESTS config.
So the full tests (CRYPTO_SELFTESTS_FULL) still haven't been run?
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: exynos-rng - Remove exynos-rng driver
From: Eric Biggers @ 2026-06-10 18:39 UTC (permalink / raw)
To: Peter Griffin
Cc: linux-crypto, Herbert Xu, linux-samsung-soc, Krzysztof Kozlowski,
Alim Akhtar, linux-kernel
In-Reply-To: <CADrjBPo3BpSk49oasf_9g06xrBMkw+NiKo10xDKjWr8sJ+Zc-Q@mail.gmail.com>
On Wed, Jun 10, 2026 at 03:46:54PM +0100, Peter Griffin wrote:
> Hi Eric,
>
> On Sun, 31 May 2026 at 19:02, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > This driver has no purpose. It doesn't feed into the Linux RNG, nor
> > does it implement the hwrng interface. It is accessible only via the
> > "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
> > uses either the Linux RNG, or rarely /dev/hwrng.
> >
> > Moreover, this is a PRNG whose only source of entropy is the 160-bit
> > seed the user passes in. So this can be used only by a user who already
> > has a source of cryptographically secure random numbers, such as
> > /dev/random. Which they can, and do, just use in the first place.
> >
> > Just remove this driver. There's no need to keep useless code around.
> >
> > Note that the other crypto_rng drivers in drivers/crypto/ are similarly
> > unused and are being removed too. This commit just handles exynos-rng.
> >
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
>
> If the driver is being removed, should the binding documentation for
> this driver not also be deleted (see
> Documentation/devicetree/bindings/rng/samsung,exynos4-rng.yaml)?
>
> Peter
In other discussions I've been told that devicetree bindings are
hardware descriptions that should still exist even if there is no
driver. It doesn't make a lot of sense, but it seems to be what the
devicetree people want. I expect there would be objections to removing
this binding.
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: ecc - Optimize vli additive operations using compiler builtins
From: Stefan Berger @ 2026-06-10 17:25 UTC (permalink / raw)
To: Fabian Blatter, lukas, ignat, herbert, davem; +Cc: linux-crypto, linux-kernel
In-Reply-To: <20260607112435.42804-1-fabianblatter09@gmail.com>
On 6/7/26 7:24 AM, Fabian Blatter wrote:
> Replace the software carry flag emulation with compiler builtins.
>
> Even the newest compilers struggle with taking advantage of the
> hardware carry flag. Compiler builtins allow the compiler to
> much more easily achieve this while still remaining constant-time.
>
> This yields an approximately 6-7% performance improvement
> on the ecc_gen_privkey, ecc_make_pub_key and crypto_ecdh_shared_secret
> functions on x86_64 on all curve sizes.
>
> Additionally, the code becomes much more readable.
>
> Signed-off-by: Fabian Blatter <fabianblatter09@gmail.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH] crypto: ecc - Optimize vli additive operations using compiler builtins
From: Fabian @ 2026-06-10 16:57 UTC (permalink / raw)
To: Stefan Berger; +Cc: lukas, ignat, herbert, davem, linux-crypto, linux-kernel
In-Reply-To: <af632d11-baea-4314-ac17-d81502240a5c@linux.ibm.com>
On Wed, 10 Jun 2026 at 16:52, Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>
>
> On 6/9/26 4:51 PM, Fabian wrote:
> > On Tue, 9 Jun 2026 at 20:58, Stefan Berger <stefanb@linux.ibm.com> wrote:
> >>
> >>
> >>
> >> On 6/7/26 7:24 AM, Fabian Blatter wrote:
> >>> Replace the software carry flag emulation with compiler builtins.
> >>>
> >>> Even the newest compilers struggle with taking advantage of the
> >>> hardware carry flag. Compiler builtins allow the compiler to
> >>> much more easily achieve this while still remaining constant-time.
> >>
> >> It looks like you made vli_usub and vli_uadd constant-time now because
> >> otherwise the loops could be ended early once borrow == 0 or carry == 0
> >> respectively. Are all the other functions that operate on the private
> >> keys constant-time?
> >>
> >
> > Thanks for the reply,
> >
> > My primary goal with this patch was performance optimization.
> > I did not add early exiting because the original version didn't either.
> >
> > To answer your question: No, some other functions in ecc.c
> > are not constant-time. For example, vli_is_zero and vli_cmp both
> > contain early exits.
> > > My patch does remove the branches in the inner loop,
> > however, the original ones were already constant-time in practice,
> > because the compiler replaces the branches with cmov's.
> > > I am happy to make any changes to this patch if you like.
>
> ecrdsa calls ecc_is_pubkey_valid_partial -> vli_mod_square_fast ->
> vli_mmod_fast and then may call vli_usub or vli_uadd via
> vli_mmod_special2 or vli_mmod_barret.
>
> ecc_point_mult operates on a private key and will call vli_mmod_fast and
> for some non-NIST keys it may call either one of vli_usub or vli_uadd
> via vli_mmod_special2 or vli_mmod_barret.
>
> Due to the private key operations it's probably better to keep the
> functions constant-time for now.
Agreed.
>
> > I could also look into making `vli_cmp` and `vli_is_zero`,
> > or others constant-time in a future patch.
>
> I wonder whether it would be practical to suffix constant-time functions
> with _ct so that it becomes visible whether the call paths of functions
> operation on private keys only call _ct functions? Sometimes one could
> optimize functions shared by private and public key operations for
> performance -- call them with 'bool ct' in this case and suffix them
> with _oct (o=optimized + ct) indicating that they support both variants?
>
I am unsure whether constant-time operations are even slower than
early-exit variants by a significant margin. vli_uadd and vli_usub
don't seem to be called that often anyways. I believe this probably
doesn't justify the resulting binary size and complexity increase.
Let me know how you'd like to move forward.
^ permalink raw reply
* Re: [PATCH] crypto: ecc - Optimize vli additive operations using compiler builtins
From: Stefan Berger @ 2026-06-10 14:52 UTC (permalink / raw)
To: Fabian; +Cc: lukas, ignat, herbert, davem, linux-crypto, linux-kernel
In-Reply-To: <CAGtAT=nJOAxecN+eYVwkzQAUcr2BaBhAO=ni9hWqdRKUQ06=fA@mail.gmail.com>
On 6/9/26 4:51 PM, Fabian wrote:
> On Tue, 9 Jun 2026 at 20:58, Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>>
>>
>> On 6/7/26 7:24 AM, Fabian Blatter wrote:
>>> Replace the software carry flag emulation with compiler builtins.
>>>
>>> Even the newest compilers struggle with taking advantage of the
>>> hardware carry flag. Compiler builtins allow the compiler to
>>> much more easily achieve this while still remaining constant-time.
>>
>> It looks like you made vli_usub and vli_uadd constant-time now because
>> otherwise the loops could be ended early once borrow == 0 or carry == 0
>> respectively. Are all the other functions that operate on the private
>> keys constant-time?
>>
>
> Thanks for the reply,
>
> My primary goal with this patch was performance optimization.
> I did not add early exiting because the original version didn't either.
>
> To answer your question: No, some other functions in ecc.c
> are not constant-time. For example, vli_is_zero and vli_cmp both
> contain early exits.
> > My patch does remove the branches in the inner loop,
> however, the original ones were already constant-time in practice,
> because the compiler replaces the branches with cmov's.
> > I am happy to make any changes to this patch if you like.
ecrdsa calls ecc_is_pubkey_valid_partial -> vli_mod_square_fast ->
vli_mmod_fast and then may call vli_usub or vli_uadd via
vli_mmod_special2 or vli_mmod_barret.
ecc_point_mult operates on a private key and will call vli_mmod_fast and
for some non-NIST keys it may call either one of vli_usub or vli_uadd
via vli_mmod_special2 or vli_mmod_barret.
Due to the private key operations it's probably better to keep the
functions constant-time for now.
> I could also look into making `vli_cmp` and `vli_is_zero`,
> or others constant-time in a future patch.
I wonder whether it would be practical to suffix constant-time functions
with _ct so that it becomes visible whether the call paths of functions
operation on private keys only call _ct functions? Sometimes one could
optimize functions shared by private and public key operations for
performance -- call them with 'bool ct' in this case and suffix them
with _oct (o=optimized + ct) indicating that they support both variants?
^ permalink raw reply
* Re: [PATCH] crypto: exynos-rng - Remove exynos-rng driver
From: Peter Griffin @ 2026-06-10 14:46 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Herbert Xu, linux-samsung-soc, Krzysztof Kozlowski,
Alim Akhtar, linux-kernel
In-Reply-To: <20260531175932.32171-1-ebiggers@kernel.org>
Hi Eric,
On Sun, 31 May 2026 at 19:02, Eric Biggers <ebiggers@kernel.org> wrote:
>
> This driver has no purpose. It doesn't feed into the Linux RNG, nor
> does it implement the hwrng interface. It is accessible only via the
> "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
> uses either the Linux RNG, or rarely /dev/hwrng.
>
> Moreover, this is a PRNG whose only source of entropy is the 160-bit
> seed the user passes in. So this can be used only by a user who already
> has a source of cryptographically secure random numbers, such as
> /dev/random. Which they can, and do, just use in the first place.
>
> Just remove this driver. There's no need to keep useless code around.
>
> Note that the other crypto_rng drivers in drivers/crypto/ are similarly
> unused and are being removed too. This commit just handles exynos-rng.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
If the driver is being removed, should the binding documentation for
this driver not also be deleted (see
Documentation/devicetree/bindings/rng/samsung,exynos4-rng.yaml)?
Peter
> MAINTAINERS | 8 -
> arch/arm/configs/exynos_defconfig | 1 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> drivers/crypto/Kconfig | 18 --
> drivers/crypto/Makefile | 1 -
> drivers/crypto/exynos-rng.c | 399 ----------------------------
> 6 files changed, 428 deletions(-)
> delete mode 100644 drivers/crypto/exynos-rng.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 882214b0e7db..a7f2762baac1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23701,18 +23701,10 @@ L: linux-samsung-soc@vger.kernel.org
> S: Supported
> F: Documentation/devicetree/bindings/mailbox/google,gs101-mbox.yaml
> F: drivers/mailbox/exynos-mailbox.c
> F: include/linux/mailbox/exynos-message.h
>
> -SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER
> -M: Krzysztof Kozlowski <krzk@kernel.org>
> -L: linux-crypto@vger.kernel.org
> -L: linux-samsung-soc@vger.kernel.org
> -S: Maintained
> -F: Documentation/devicetree/bindings/rng/samsung,exynos4-rng.yaml
> -F: drivers/crypto/exynos-rng.c
> -
> SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
> M: Łukasz Stelmach <l.stelmach@samsung.com>
> L: linux-samsung-soc@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 84070e9698e8..8b072a5c0a5e 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -362,11 +362,10 @@ CONFIG_CRYPTO_LZ4=m
> CONFIG_CRYPTO_USER_API_HASH=m
> CONFIG_CRYPTO_USER_API_SKCIPHER=m
> CONFIG_CRYPTO_USER_API_RNG=m
> CONFIG_CRYPTO_USER_API_AEAD=m
> CONFIG_CRYPTO_AES_ARM_BS=m
> -CONFIG_CRYPTO_DEV_EXYNOS_RNG=y
> CONFIG_CRYPTO_DEV_S5P=y
> CONFIG_DMA_CMA=y
> CONFIG_CMA_SIZE_MBYTES=96
> CONFIG_FONTS=y
> CONFIG_FONT_7x14=y
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index bcc9aabc1202..3672dd12df60 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -1327,11 +1327,10 @@ CONFIG_CRYPTO_GHASH_ARM_CE=m
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_AES_ARM_BS=m
> CONFIG_CRYPTO_AES_ARM_CE=m
> CONFIG_CRYPTO_DEV_SUN4I_SS=m
> CONFIG_CRYPTO_DEV_FSL_CAAM=m
> -CONFIG_CRYPTO_DEV_EXYNOS_RNG=m
> CONFIG_CRYPTO_DEV_S5P=m
> CONFIG_CRYPTO_DEV_ATMEL_AES=m
> CONFIG_CRYPTO_DEV_ATMEL_TDES=m
> CONFIG_CRYPTO_DEV_ATMEL_SHA=m
> CONFIG_CRYPTO_DEV_MARVELL_CESA=m
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 3449b3c9c6ad..39c7b195bb33 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -373,25 +373,10 @@ config CRYPTO_DEV_SAHARA
> select CRYPTO_ENGINE
> help
> This option enables support for the SAHARA HW crypto accelerator
> found in some Freescale i.MX chips.
>
> -config CRYPTO_DEV_EXYNOS_RNG
> - tristate "Exynos HW pseudo random number generator support"
> - depends on ARCH_EXYNOS || COMPILE_TEST
> - depends on HAS_IOMEM
> - select CRYPTO_RNG
> - help
> - This driver provides kernel-side support through the
> - cryptographic API for the pseudo random number generator hardware
> - found on Exynos SoCs.
> -
> - To compile this driver as a module, choose M here: the
> - module will be called exynos-rng.
> -
> - If unsure, say Y.
> -
> config CRYPTO_DEV_S5P
> tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
> depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
> depends on HAS_IOMEM
> select CRYPTO_AES
> @@ -402,20 +387,17 @@ config CRYPTO_DEV_S5P
> algorithms execution.
>
> config CRYPTO_DEV_EXYNOS_HASH
> bool "Support for Samsung Exynos HASH accelerator"
> depends on CRYPTO_DEV_S5P
> - depends on !CRYPTO_DEV_EXYNOS_RNG && CRYPTO_DEV_EXYNOS_RNG!=m
> select CRYPTO_SHA1
> select CRYPTO_MD5
> select CRYPTO_SHA256
> help
> Select this to offload Exynos from HASH MD5/SHA1/SHA256.
> This will select software SHA1, MD5 and SHA256 as they are
> needed for small and zero-size messages.
> - HASH algorithms will be disabled if EXYNOS_RNG
> - is enabled due to hw conflict.
>
> config CRYPTO_DEV_NX
> bool "Support for IBM PowerPC Nest (NX) cryptographic acceleration"
> depends on PPC64
> help
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 283bbc650b5b..e141ab0dd741 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -9,11 +9,10 @@ obj-$(CONFIG_CRYPTO_DEV_ATMEL_I2C) += atmel-i2c.o
> obj-$(CONFIG_CRYPTO_DEV_ATMEL_ECC) += atmel-ecc.o
> obj-$(CONFIG_CRYPTO_DEV_ATMEL_SHA204A) += atmel-sha204a.o
> obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/
> obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
> obj-$(CONFIG_CRYPTO_DEV_CHELSIO) += chelsio/
> -obj-$(CONFIG_CRYPTO_DEV_EXYNOS_RNG) += exynos-rng.o
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON) += caam/
> obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
> obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
> obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
> obj-$(CONFIG_CRYPTO_DEV_MARVELL) += marvell/
> diff --git a/drivers/crypto/exynos-rng.c b/drivers/crypto/exynos-rng.c
> deleted file mode 100644
> index 2aaa98f9b44e..000000000000
> --- a/drivers/crypto/exynos-rng.c
> +++ /dev/null
> @@ -1,399 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * exynos-rng.c - Random Number Generator driver for the Exynos
> - *
> - * Copyright (c) 2017 Krzysztof Kozlowski <krzk@kernel.org>
> - *
> - * Loosely based on old driver from drivers/char/hw_random/exynos-rng.c:
> - * Copyright (C) 2012 Samsung Electronics
> - * Jonghwa Lee <jonghwa3.lee@samsung.com>
> - */
> -
> -#include <linux/clk.h>
> -#include <linux/crypto.h>
> -#include <linux/err.h>
> -#include <linux/io.h>
> -#include <linux/module.h>
> -#include <linux/mutex.h>
> -#include <linux/of.h>
> -#include <linux/platform_device.h>
> -
> -#include <crypto/internal/rng.h>
> -
> -#define EXYNOS_RNG_CONTROL 0x0
> -#define EXYNOS_RNG_STATUS 0x10
> -
> -#define EXYNOS_RNG_SEED_CONF 0x14
> -#define EXYNOS_RNG_GEN_PRNG BIT(1)
> -
> -#define EXYNOS_RNG_SEED_BASE 0x140
> -#define EXYNOS_RNG_SEED(n) (EXYNOS_RNG_SEED_BASE + (n * 0x4))
> -#define EXYNOS_RNG_OUT_BASE 0x160
> -#define EXYNOS_RNG_OUT(n) (EXYNOS_RNG_OUT_BASE + (n * 0x4))
> -
> -/* EXYNOS_RNG_CONTROL bit fields */
> -#define EXYNOS_RNG_CONTROL_START 0x18
> -/* EXYNOS_RNG_STATUS bit fields */
> -#define EXYNOS_RNG_STATUS_SEED_SETTING_DONE BIT(1)
> -#define EXYNOS_RNG_STATUS_RNG_DONE BIT(5)
> -
> -/* Five seed and output registers, each 4 bytes */
> -#define EXYNOS_RNG_SEED_REGS 5
> -#define EXYNOS_RNG_SEED_SIZE (EXYNOS_RNG_SEED_REGS * 4)
> -
> -enum exynos_prng_type {
> - EXYNOS_PRNG_UNKNOWN = 0,
> - EXYNOS_PRNG_EXYNOS4,
> - EXYNOS_PRNG_EXYNOS5,
> -};
> -
> -/*
> - * Driver re-seeds itself with generated random numbers to hinder
> - * backtracking of the original seed.
> - *
> - * Time for next re-seed in ms.
> - */
> -#define EXYNOS_RNG_RESEED_TIME 1000
> -#define EXYNOS_RNG_RESEED_BYTES 65536
> -
> -/*
> - * In polling mode, do not wait infinitely for the engine to finish the work.
> - */
> -#define EXYNOS_RNG_WAIT_RETRIES 100
> -
> -/* Context for crypto */
> -struct exynos_rng_ctx {
> - struct exynos_rng_dev *rng;
> -};
> -
> -/* Device associated memory */
> -struct exynos_rng_dev {
> - struct device *dev;
> - enum exynos_prng_type type;
> - void __iomem *mem;
> - struct clk *clk;
> - struct mutex lock;
> - /* Generated numbers stored for seeding during resume */
> - u8 seed_save[EXYNOS_RNG_SEED_SIZE];
> - unsigned int seed_save_len;
> - /* Time of last seeding in jiffies */
> - unsigned long last_seeding;
> - /* Bytes generated since last seeding */
> - unsigned long bytes_seeding;
> -};
> -
> -static struct exynos_rng_dev *exynos_rng_dev;
> -
> -static u32 exynos_rng_readl(struct exynos_rng_dev *rng, u32 offset)
> -{
> - return readl_relaxed(rng->mem + offset);
> -}
> -
> -static void exynos_rng_writel(struct exynos_rng_dev *rng, u32 val, u32 offset)
> -{
> - writel_relaxed(val, rng->mem + offset);
> -}
> -
> -static int exynos_rng_set_seed(struct exynos_rng_dev *rng,
> - const u8 *seed, unsigned int slen)
> -{
> - u32 val;
> - int i;
> -
> - /* Round seed length because loop iterates over full register size */
> - slen = ALIGN_DOWN(slen, 4);
> -
> - if (slen < EXYNOS_RNG_SEED_SIZE)
> - return -EINVAL;
> -
> - for (i = 0; i < slen ; i += 4) {
> - unsigned int seed_reg = (i / 4) % EXYNOS_RNG_SEED_REGS;
> -
> - val = seed[i] << 24;
> - val |= seed[i + 1] << 16;
> - val |= seed[i + 2] << 8;
> - val |= seed[i + 3] << 0;
> -
> - exynos_rng_writel(rng, val, EXYNOS_RNG_SEED(seed_reg));
> - }
> -
> - val = exynos_rng_readl(rng, EXYNOS_RNG_STATUS);
> - if (!(val & EXYNOS_RNG_STATUS_SEED_SETTING_DONE)) {
> - dev_warn(rng->dev, "Seed setting not finished\n");
> - return -EIO;
> - }
> -
> - rng->last_seeding = jiffies;
> - rng->bytes_seeding = 0;
> -
> - return 0;
> -}
> -
> -/*
> - * Start the engine and poll for finish. Then read from output registers
> - * filling the 'dst' buffer up to 'dlen' bytes or up to size of generated
> - * random data (EXYNOS_RNG_SEED_SIZE).
> - *
> - * On success: return 0 and store number of read bytes under 'read' address.
> - * On error: return -ERRNO.
> - */
> -static int exynos_rng_get_random(struct exynos_rng_dev *rng,
> - u8 *dst, unsigned int dlen,
> - unsigned int *read)
> -{
> - int retry = EXYNOS_RNG_WAIT_RETRIES;
> -
> - if (rng->type == EXYNOS_PRNG_EXYNOS4) {
> - exynos_rng_writel(rng, EXYNOS_RNG_CONTROL_START,
> - EXYNOS_RNG_CONTROL);
> - } else if (rng->type == EXYNOS_PRNG_EXYNOS5) {
> - exynos_rng_writel(rng, EXYNOS_RNG_GEN_PRNG,
> - EXYNOS_RNG_SEED_CONF);
> - }
> -
> - while (!(exynos_rng_readl(rng,
> - EXYNOS_RNG_STATUS) & EXYNOS_RNG_STATUS_RNG_DONE) && --retry)
> - cpu_relax();
> -
> - if (!retry)
> - return -ETIMEDOUT;
> -
> - /* Clear status bit */
> - exynos_rng_writel(rng, EXYNOS_RNG_STATUS_RNG_DONE,
> - EXYNOS_RNG_STATUS);
> - *read = min_t(size_t, dlen, EXYNOS_RNG_SEED_SIZE);
> - memcpy_fromio(dst, rng->mem + EXYNOS_RNG_OUT_BASE, *read);
> - rng->bytes_seeding += *read;
> -
> - return 0;
> -}
> -
> -/* Re-seed itself from time to time */
> -static void exynos_rng_reseed(struct exynos_rng_dev *rng)
> -{
> - unsigned long next_seeding = rng->last_seeding + \
> - msecs_to_jiffies(EXYNOS_RNG_RESEED_TIME);
> - unsigned long now = jiffies;
> - unsigned int read = 0;
> - u8 seed[EXYNOS_RNG_SEED_SIZE];
> -
> - if (time_before(now, next_seeding) &&
> - rng->bytes_seeding < EXYNOS_RNG_RESEED_BYTES)
> - return;
> -
> - if (exynos_rng_get_random(rng, seed, sizeof(seed), &read))
> - return;
> -
> - exynos_rng_set_seed(rng, seed, read);
> -
> - /* Let others do some of their job. */
> - mutex_unlock(&rng->lock);
> - mutex_lock(&rng->lock);
> -}
> -
> -static int exynos_rng_generate(struct crypto_rng *tfm,
> - const u8 *src, unsigned int slen,
> - u8 *dst, unsigned int dlen)
> -{
> - struct exynos_rng_ctx *ctx = crypto_rng_ctx(tfm);
> - struct exynos_rng_dev *rng = ctx->rng;
> - unsigned int read = 0;
> - int ret;
> -
> - ret = clk_prepare_enable(rng->clk);
> - if (ret)
> - return ret;
> -
> - mutex_lock(&rng->lock);
> - do {
> - ret = exynos_rng_get_random(rng, dst, dlen, &read);
> - if (ret)
> - break;
> -
> - dlen -= read;
> - dst += read;
> -
> - exynos_rng_reseed(rng);
> - } while (dlen > 0);
> - mutex_unlock(&rng->lock);
> -
> - clk_disable_unprepare(rng->clk);
> -
> - return ret;
> -}
> -
> -static int exynos_rng_seed(struct crypto_rng *tfm, const u8 *seed,
> - unsigned int slen)
> -{
> - struct exynos_rng_ctx *ctx = crypto_rng_ctx(tfm);
> - struct exynos_rng_dev *rng = ctx->rng;
> - int ret;
> -
> - ret = clk_prepare_enable(rng->clk);
> - if (ret)
> - return ret;
> -
> - mutex_lock(&rng->lock);
> - ret = exynos_rng_set_seed(ctx->rng, seed, slen);
> - mutex_unlock(&rng->lock);
> -
> - clk_disable_unprepare(rng->clk);
> -
> - return ret;
> -}
> -
> -static int exynos_rng_kcapi_init(struct crypto_tfm *tfm)
> -{
> - struct exynos_rng_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - ctx->rng = exynos_rng_dev;
> -
> - return 0;
> -}
> -
> -static struct rng_alg exynos_rng_alg = {
> - .generate = exynos_rng_generate,
> - .seed = exynos_rng_seed,
> - .seedsize = EXYNOS_RNG_SEED_SIZE,
> - .base = {
> - .cra_name = "stdrng",
> - .cra_driver_name = "exynos_rng",
> - .cra_priority = 300,
> - .cra_ctxsize = sizeof(struct exynos_rng_ctx),
> - .cra_module = THIS_MODULE,
> - .cra_init = exynos_rng_kcapi_init,
> - }
> -};
> -
> -static int exynos_rng_probe(struct platform_device *pdev)
> -{
> - struct exynos_rng_dev *rng;
> - int ret;
> -
> - if (exynos_rng_dev)
> - return -EEXIST;
> -
> - rng = devm_kzalloc(&pdev->dev, sizeof(*rng), GFP_KERNEL);
> - if (!rng)
> - return -ENOMEM;
> -
> - rng->type = (uintptr_t)of_device_get_match_data(&pdev->dev);
> -
> - mutex_init(&rng->lock);
> -
> - rng->dev = &pdev->dev;
> - rng->clk = devm_clk_get(&pdev->dev, "secss");
> - if (IS_ERR(rng->clk)) {
> - dev_err(&pdev->dev, "Couldn't get clock.\n");
> - return PTR_ERR(rng->clk);
> - }
> -
> - rng->mem = devm_platform_ioremap_resource(pdev, 0);
> - if (IS_ERR(rng->mem))
> - return PTR_ERR(rng->mem);
> -
> - platform_set_drvdata(pdev, rng);
> -
> - exynos_rng_dev = rng;
> -
> - ret = crypto_register_rng(&exynos_rng_alg);
> - if (ret) {
> - dev_err(&pdev->dev,
> - "Couldn't register rng crypto alg: %d\n", ret);
> - exynos_rng_dev = NULL;
> - }
> -
> - return ret;
> -}
> -
> -static void exynos_rng_remove(struct platform_device *pdev)
> -{
> - crypto_unregister_rng(&exynos_rng_alg);
> -
> - exynos_rng_dev = NULL;
> -}
> -
> -static int __maybe_unused exynos_rng_suspend(struct device *dev)
> -{
> - struct exynos_rng_dev *rng = dev_get_drvdata(dev);
> - int ret;
> -
> - /* If we were never seeded then after resume it will be the same */
> - if (!rng->last_seeding)
> - return 0;
> -
> - rng->seed_save_len = 0;
> - ret = clk_prepare_enable(rng->clk);
> - if (ret)
> - return ret;
> -
> - mutex_lock(&rng->lock);
> -
> - /* Get new random numbers and store them for seeding on resume. */
> - exynos_rng_get_random(rng, rng->seed_save, sizeof(rng->seed_save),
> - &(rng->seed_save_len));
> -
> - mutex_unlock(&rng->lock);
> -
> - dev_dbg(rng->dev, "Stored %u bytes for seeding on system resume\n",
> - rng->seed_save_len);
> -
> - clk_disable_unprepare(rng->clk);
> -
> - return 0;
> -}
> -
> -static int __maybe_unused exynos_rng_resume(struct device *dev)
> -{
> - struct exynos_rng_dev *rng = dev_get_drvdata(dev);
> - int ret;
> -
> - /* Never seeded so nothing to do */
> - if (!rng->last_seeding)
> - return 0;
> -
> - ret = clk_prepare_enable(rng->clk);
> - if (ret)
> - return ret;
> -
> - mutex_lock(&rng->lock);
> -
> - ret = exynos_rng_set_seed(rng, rng->seed_save, rng->seed_save_len);
> -
> - mutex_unlock(&rng->lock);
> -
> - clk_disable_unprepare(rng->clk);
> -
> - return ret;
> -}
> -
> -static SIMPLE_DEV_PM_OPS(exynos_rng_pm_ops, exynos_rng_suspend,
> - exynos_rng_resume);
> -
> -static const struct of_device_id exynos_rng_dt_match[] = {
> - {
> - .compatible = "samsung,exynos4-rng",
> - .data = (const void *)EXYNOS_PRNG_EXYNOS4,
> - }, {
> - .compatible = "samsung,exynos5250-prng",
> - .data = (const void *)EXYNOS_PRNG_EXYNOS5,
> - },
> - { },
> -};
> -MODULE_DEVICE_TABLE(of, exynos_rng_dt_match);
> -
> -static struct platform_driver exynos_rng_driver = {
> - .driver = {
> - .name = "exynos-rng",
> - .pm = &exynos_rng_pm_ops,
> - .of_match_table = exynos_rng_dt_match,
> - },
> - .probe = exynos_rng_probe,
> - .remove = exynos_rng_remove,
> -};
> -
> -module_platform_driver(exynos_rng_driver);
> -
> -MODULE_DESCRIPTION("Exynos H/W Random Number Generator driver");
> -MODULE_AUTHOR("Krzysztof Kozlowski <krzk@kernel.org>");
> -MODULE_LICENSE("GPL v2");
>
> base-commit: 5624ea54f3ba5c83d2e5503411a31a8be0278c1e
> --
> 2.54.0
>
>
^ permalink raw reply
* Re: [PATCH 17/29] crypto: talitos/aead - Use macro for algorithm definitions
From: Paul Louvel @ 2026-06-10 14:41 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), Paul Louvel, Herbert Xu,
David S. Miller
Cc: Thomas Petazzoni, Herve Codina, linux-crypto, linux-kernel
In-Reply-To: <30919934-0baf-47c3-a601-3ff0c8cc7f43@kernel.org>
Hi Christophe,
On Mon Jun 1, 2026 at 2:12 PM CEST, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 28/05/2026 à 11:08, Paul Louvel a écrit :
>> Replace the repetitive struct initializer entries in aead_driver_algs[]
>> with preprocessor macros (TALITOS_AEAD_ALG, TALITOS_AEAD_ALG_HSNA).
>>
>> Move the function pointer assignments (init, exit, encrypt, decrypt)
>> from the registration loop into the static initializer, since they are
>> identical for all algorithms.
>>
>> The fallback setkey assignment (aead_alg->setkey ?: aead_setkey) is
>> replaced by specifying the correct setkey handler directly in each macro
>> invocation.
>>
>> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
>
> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
>
> Wondering if we could go even more far with the COMMON flags, as for
> instance all TALITOS_AEAD_ALG_HSNA have DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU
> while TALITOS_AEAD_ALG have DESC_HDR_TYPE_IPSEC_ESP
>
I tried going as far as possible, but it make a mess of macros. Even if there is
repetition here (there is outside your example) for the template, I think this
is better if this is kept as is.
>> ---
>> drivers/crypto/talitos/talitos-aead.c | 751 ++++++++++------------------------
>> 1 file changed, 218 insertions(+), 533 deletions(-)
>>
>> diff --git a/drivers/crypto/talitos/talitos-aead.c b/drivers/crypto/talitos/talitos-aead.c
>> index 38df616c9b22..cd1b8e6d371b 100644
>> --- a/drivers/crypto/talitos/talitos-aead.c
>> +++ b/drivers/crypto/talitos/talitos-aead.c
>> @@ -405,535 +405,225 @@ static void talitos_cra_exit_aead(struct crypto_aead *tfm)
>> talitos_cra_exit(crypto_aead_tfm(tfm));
>> }
>>
>> +#define TALITOS_AEAD_ALG_COMMON(name, name_prefix, set_key, block_size, \
>> + max_auth_size, template, priority) \
>> + { \
>> + .type = CRYPTO_ALG_TYPE_AEAD, \
>> + .alg.aead = { \
>> + .base = { \
>> + .cra_name = name, \
>> + .cra_driver_name = name"-talitos"name_prefix, \
>> + .cra_blocksize = block_size, \
>> + .cra_flags = CRYPTO_ALG_ASYNC | \
>> + CRYPTO_ALG_ALLOCATES_MEMORY | \
>> + CRYPTO_ALG_KERN_DRIVER_ONLY, \
>> + .cra_priority = (priority), \
>> + .cra_ctxsize = sizeof(struct talitos_ctx), \
>> + .cra_module = THIS_MODULE, \
>> + }, \
>> + .ivsize = block_size, \
>> + .maxauthsize = max_auth_size, \
>> + .setkey = set_key, \
>> + .init = talitos_cra_init_aead, \
>> + .exit = talitos_cra_exit_aead, \
>> + .encrypt = aead_encrypt, \
>> + .decrypt = aead_decrypt, \
>> + }, \
>> + .desc_hdr_template = template, \
>> + }
>> +
>> +#define TALITOS_AEAD_ALG(name, set_key, block_size, max_auth_size, template) \
>> + TALITOS_AEAD_ALG_COMMON(name, "", set_key, block_size, max_auth_size, \
>> + template, TALITOS_CRA_PRIORITY)
>> +
>> +#define TALITOS_AEAD_ALG_HSNA(name, set_key, block_size, max_auth_size, \
>> + template) \
>> + TALITOS_AEAD_ALG_COMMON(name, "-hsna", set_key, block_size, \
>> + max_auth_size, template, \
>> + TALITOS_CRA_PRIORITY_AEAD_HSNA)
>> +
>> static struct talitos_alg_template aead_driver_algs[] = {
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha1),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha1-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA1_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA1_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha1),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha1-"
>> - "cbc-aes-talitos-hsna",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA1_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA1_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha1),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha1-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA1_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA1_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha1),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha1-"
>> - "cbc-3des-talitos-hsna",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA1_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA1_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha224),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha224-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA224_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA224_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha224),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha224-"
>> - "cbc-aes-talitos-hsna",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA224_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA224_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha224),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha224-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA224_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA224_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha224),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha224-"
>> - "cbc-3des-talitos-hsna",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA224_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA224_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha256),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha256-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA256_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA256_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha256),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha256-"
>> - "cbc-aes-talitos-hsna",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA256_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA256_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha256),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha256-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA256_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA256_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha256),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha256-"
>> - "cbc-3des-talitos-hsna",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA256_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_SHA256_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha384),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha384-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA384_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUB |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEUB_SHA384_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha384),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha384-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA384_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUB |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEUB_SHA384_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha512),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-sha512-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = SHA512_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUB |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEUB_SHA512_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(sha512),"
>> - "cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-sha512-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = SHA512_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUB |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEUB_SHA512_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(md5),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-md5-"
>> - "cbc-aes-talitos",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = MD5_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_MD5_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(md5),cbc(aes))",
>> - .cra_driver_name = "authenc-hmac-md5-"
>> - "cbc-aes-talitos-hsna",
>> - .cra_blocksize = AES_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = AES_BLOCK_SIZE,
>> - .maxauthsize = MD5_DIGEST_SIZE,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_AESU |
>> - DESC_HDR_MODE0_AESU_CBC |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_MD5_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(md5),cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-md5-"
>> - "cbc-3des-talitos",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = MD5_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_IPSEC_ESP |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_MD5_HMAC,
>> - },
>> - { .type = CRYPTO_ALG_TYPE_AEAD,
>> - .alg.aead = {
>> - .base = {
>> - .cra_name = "authenc(hmac(md5),cbc(des3_ede))",
>> - .cra_driver_name = "authenc-hmac-md5-"
>> - "cbc-3des-talitos-hsna",
>> - .cra_blocksize = DES3_EDE_BLOCK_SIZE,
>> - .cra_flags = CRYPTO_ALG_ASYNC |
>> - CRYPTO_ALG_ALLOCATES_MEMORY |
>> - CRYPTO_ALG_KERN_DRIVER_ONLY,
>> - .cra_priority = TALITOS_CRA_PRIORITY_AEAD_HSNA,
>> - .cra_ctxsize = sizeof(struct talitos_ctx),
>> - .cra_module = THIS_MODULE,
>> - },
>> - .ivsize = DES3_EDE_BLOCK_SIZE,
>> - .maxauthsize = MD5_DIGEST_SIZE,
>> - .setkey = aead_des3_setkey,
>> - },
>> - .desc_hdr_template = DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU |
>> - DESC_HDR_SEL0_DEU |
>> - DESC_HDR_MODE0_DEU_CBC |
>> - DESC_HDR_MODE0_DEU_3DES |
>> - DESC_HDR_SEL1_MDEUA |
>> - DESC_HDR_MODE1_MDEU_INIT |
>> - DESC_HDR_MODE1_MDEU_PAD |
>> - DESC_HDR_MODE1_MDEU_MD5_HMAC,
>> - },
>> + /* AEAD algorithms. These use a single-pass ipsec_esp descriptor */
>> +
>> + /* sha1 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha1),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, SHA1_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA1_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha1),cbc(aes))", aead_setkey, AES_BLOCK_SIZE,
>> + SHA1_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT | DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA1_HMAC),
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha1),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA1_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC |
>> + DESC_HDR_MODE0_DEU_3DES | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA1_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha1),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA1_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA1_HMAC),
>> +
>> + /* sha224 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha224),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, SHA224_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA224_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha224),cbc(aes))", aead_setkey, AES_BLOCK_SIZE,
>> + SHA224_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT | DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA224_HMAC),
>> +
>> + TALITOS_AEAD_ALG(
>> + "authenc(hmac(sha224),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA224_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA224_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha224),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA224_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA224_HMAC),
>> +
>> + /* sha256 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha256),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, SHA256_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA256_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha256),cbc(aes))", aead_setkey, AES_BLOCK_SIZE,
>> + SHA256_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT | DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA256_HMAC),
>> +
>> + TALITOS_AEAD_ALG(
>> + "authenc(hmac(sha256),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA256_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA256_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(sha256),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA256_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_SHA256_HMAC),
>> +
>> + /* sha384 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha384),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, SHA384_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUB |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEUB_SHA384_HMAC),
>> +
>> + TALITOS_AEAD_ALG(
>> + "authenc(hmac(sha384),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA384_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUB | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEUB_SHA384_HMAC),
>> +
>> + /* sha512 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(sha512),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, SHA512_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUB |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEUB_SHA512_HMAC),
>> +
>> + TALITOS_AEAD_ALG(
>> + "authenc(hmac(sha512),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, SHA512_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUB | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEUB_SHA512_HMAC),
>> +
>> + /* md5 auth */
>> +
>> + TALITOS_AEAD_ALG("authenc(hmac(md5),cbc(aes))", aead_setkey,
>> + AES_BLOCK_SIZE, MD5_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_MD5_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(md5),cbc(aes))", aead_setkey, AES_BLOCK_SIZE,
>> + MD5_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_AESU |
>> + DESC_HDR_MODE0_AESU_CBC | DESC_HDR_SEL1_MDEUA |
>> + DESC_HDR_MODE1_MDEU_INIT | DESC_HDR_MODE1_MDEU_PAD |
>> + DESC_HDR_MODE1_MDEU_MD5_HMAC),
>> +
>> + TALITOS_AEAD_ALG(
>> + "authenc(hmac(md5),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, MD5_DIGEST_SIZE,
>> + DESC_HDR_TYPE_IPSEC_ESP | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD | DESC_HDR_MODE1_MDEU_MD5_HMAC),
>> +
>> + TALITOS_AEAD_ALG_HSNA(
>> + "authenc(hmac(md5),cbc(des3_ede))", aead_des3_setkey,
>> + DES3_EDE_BLOCK_SIZE, MD5_DIGEST_SIZE,
>> + DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU | DESC_HDR_SEL0_DEU |
>> + DESC_HDR_MODE0_DEU_CBC | DESC_HDR_MODE0_DEU_3DES |
>> + DESC_HDR_SEL1_MDEUA | DESC_HDR_MODE1_MDEU_INIT |
>> + DESC_HDR_MODE1_MDEU_PAD | DESC_HDR_MODE1_MDEU_MD5_HMAC),
>> };
>>
>> int talitos_register_aead(struct device *dev)
>> @@ -955,11 +645,6 @@ int talitos_register_aead(struct device *dev)
>> if (has_ftr_sec1(priv))
>> alg->cra_alignmask = 3;
>>
>> - aead_alg->init = talitos_cra_init_aead;
>> - aead_alg->exit = talitos_cra_exit_aead;
>> - aead_alg->setkey = aead_alg->setkey ?: aead_setkey;
>> - aead_alg->encrypt = aead_encrypt;
>> - aead_alg->decrypt = aead_decrypt;
>> if (!(priv->features & TALITOS_FTR_SHA224_HWINIT) &&
>> !strncmp(alg->cra_name, "authenc(hmac(sha224)", 20)) {
>> continue;
>>
Thanks,
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox