* [PATCH v6 04/17] lib/crypto: Move the SHA3 Iota transform into the single round function
From: David Howells @ 2025-10-17 14:42 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel
In-Reply-To: <20251017144311.817771-1-dhowells@redhat.com>
In crypto/sha3_generic.c, the keccakf() function calls keccakf_round() to
do most of the transforms, but not the Iota transform - presumably because
that is dependent on round number, whereas the Theta, Rho, Pi and Chi
transforms are not.
Note that the keccakf_round() function needs to be explicitly non-inlined
on certain architectures as gcc's produced output will (or used to) use
over 1KiB of stack space if inlined.
Now, this code was copied more or less verbatim into lib/crypto/sha3.c, so
that has the same aesthetic issue. Fix this there by passing the round
number into sha3_keccakf_one_round_generic() and doing the Iota transform
there.
crypto/sha3_generic.c is left untouched as that will be converted to use
lib/crypto/sha3.c at some point.
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Jason A. Donenfeld <Jason@zx2c4.com>
cc: Ard Biesheuvel <ardb@kernel.org>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: Stephan Mueller <smueller@chronox.de>
cc: linux-crypto@vger.kernel.org
---
lib/crypto/sha3.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lib/crypto/sha3.c b/lib/crypto/sha3.c
index 5f847a5eecdc..2c292b0b3db3 100644
--- a/lib/crypto/sha3.c
+++ b/lib/crypto/sha3.c
@@ -48,7 +48,8 @@ static const u64 sha3_keccakf_rndc[24] = {
/*
* Perform a single round of Keccak mixing.
*/
-static SHA3_INLINE void sha3_keccakf_one_round_generic(struct sha3_state *state)
+static SHA3_INLINE void sha3_keccakf_one_round_generic(struct sha3_state *state,
+ int round)
{
u64 *st = state->st;
u64 t[5], tt, bc[5];
@@ -150,15 +151,15 @@ static SHA3_INLINE void sha3_keccakf_one_round_generic(struct sha3_state *state)
st[22] ^= bc[ 2];
st[23] ^= bc[ 3];
st[24] ^= bc[ 4];
+
+ /* Iota */
+ state->st[0] ^= sha3_keccakf_rndc[round];
}
static void sha3_keccakf_rounds_generic(struct sha3_state *state)
{
- for (int round = 0; round < SHA3_KECCAK_ROUNDS; round++) {
- sha3_keccakf_one_round_generic(state);
- /* Iota */
- state->st[0] ^= sha3_keccakf_rndc[round];
- }
+ for (int round = 0; round < SHA3_KECCAK_ROUNDS; round++)
+ sha3_keccakf_one_round_generic(state, round);
}
/*
^ permalink raw reply related
* [PATCH v6 03/17] lib/crypto: Add SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256
From: David Howells @ 2025-10-17 14:42 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel
In-Reply-To: <20251017144311.817771-1-dhowells@redhat.com>
Add SHA3, providing SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 and
SHAKE256 to lib/crypto.
Notes:
(1) I've left hooks in sha3.c for asm-optimised variants, but as I don't
entirely know what those might look like, not having implemented any,
the hooks' usability is uncertain.
(2) The SHAKE algorithms will be required for ML-DSA.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Jason A. Donenfeld <Jason@zx2c4.com>
cc: Ard Biesheuvel <ardb@kernel.org>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: Stephan Mueller <smueller@chronox.de>
cc: linux-crypto@vger.kernel.org
Changes
=======
v4)
- Doc fixes:
- Fix the description of the algorithm to be closer to the NIST spec's
terminology.
- Don't talk of finialising the context for XOFs.
- Don't say "Return: None".
- Declare the "Context" to be "Any context" and make no mention of the
fact that it might use the FPU.
- Change "initialise" to "initialize".
- Don't warn that the context is relatively large for stack use.
- Use size_t for size parameters/variables.
- Make the module_exit unconditional.
v3)
- Split the s390 function rename out to a separate patch.
v2)
- Simplify things by keeping the state array in LE form and byteswapping
all the 64-bit words before and after applying the keccak function on a
BE system. This means no byteswapping is required when XOR'ing data
into the state array or when extracting the digest. Further, this is a
no-op on LE systems.
- Rename sha3_final() to sha3_squeeze() and don't clear the context at the
end as it's permitted to continue calling sha3_final() to extract
continuations of the digest (needed by ML-DSA).
- Don't reapply the end marker to the hash state in continuation
sha3_squeeze() unless sha3_update() gets called again (needed by
ML-DSA).
- Give sha3_squeeze() the amount of digest to produce as a parameter
rather than using ctx->digest_size and don't return the amount digested.
- Reimplement sha3_final() as a wrapper around sha3_squeeze() that
extracts ctx->digest_size amount of digest and then zeroes out the
context. The latter is necessary to avoid upsetting
hash-test-template.h.
- Provide a sha3_reinit() function to clear the state, but to leave the
parameters that indicate the hash properties unaffected, allowing for
reuse.
- Provide a sha3_set_digestsize() function to change the size of the
digest to be extracted by sha3_final(). sha3_squeeze() takes a
parameter for this instead.
- Don't pass the digest size as a parameter to shake128/256_init() but
rather default to 128/256 bits as per the function name.
- Provide a sha3_clear() function to zero out the context.
---
Documentation/crypto/index.rst | 1 +
Documentation/crypto/sha3.rst | 241 ++++++++++++++++
include/crypto/sha3.h | 433 +++++++++++++++++++++++++++-
lib/crypto/Kconfig | 7 +
lib/crypto/Makefile | 6 +
lib/crypto/sha3.c | 511 +++++++++++++++++++++++++++++++++
6 files changed, 1198 insertions(+), 1 deletion(-)
create mode 100644 Documentation/crypto/sha3.rst
create mode 100644 lib/crypto/sha3.c
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index 100b47d049c0..4ee667c446f9 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -27,3 +27,4 @@ for cryptographic use cases, as well as programming examples.
descore-readme
device_drivers/index
krb5
+ sha3
diff --git a/Documentation/crypto/sha3.rst b/Documentation/crypto/sha3.rst
new file mode 100644
index 000000000000..3255618ea2ec
--- /dev/null
+++ b/Documentation/crypto/sha3.rst
@@ -0,0 +1,241 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================
+SHA-3 Algorithm collection
+==========================
+
+.. Contents:
+
+ - Overview
+ - Basic API
+ - Extendable-Output Functions
+ - Convenience API
+ - Internal API
+ - Testing
+ - References
+ - API Function Reference
+
+
+Overview
+========
+
+The SHA-3 algorithm base, as specified in NIST FIPS-202[1], provides a number
+of specific variants all based on the same basic algorithm (the Keccak sponge
+function and permutation). The differences between them are: the "rate" (how
+much of the common state buffer gets updated with new data between invocations
+of the Keccak function and analogous to the "block size"), what domain
+separation suffix/padding gets appended to the message and how much data is
+extracted at the end. The Keccak sponge function is designed such that
+arbitrary amounts of output can be obtained for certain algorithms.
+
+Four standard digest algorithms are provided:
+
+ - SHA3-224
+ - SHA3-256
+ - SHA3-384
+ - SHA3-512
+
+and two Extendable-Output Functions (XOF):
+
+ - SHAKE128
+ - SHAKE256
+
+If selectable algorithms are required then the crypto_hash API may be used
+instead as this binds each algorithm to a specific C type.
+
+
+Basic API
+=========
+
+The basic API has a separate context struct for each algorithm in the SHA3
+suite, none of the contents of which are expected to be accessed directly::
+
+ struct sha3_224_ctx { ... };
+ struct sha3_256_ctx { ... };
+ struct sha3_384_ctx { ... };
+ struct sha3_512_ctx { ... };
+ struct shake128_ctx { ... };
+ struct shake256_ctx { ... };
+
+There are a collection of initialisation functions, one for each algorithm
+supported, that initialise the context appropriately for that algorithm::
+
+ void sha3_224_init(struct sha3_224_ctx *ctx);
+ void sha3_256_init(struct sha3_256_ctx *ctx);
+ void sha3_384_init(struct sha3_384_ctx *ctx);
+ void sha3_512_init(struct sha3_512_ctx *ctx);
+ void shake128_init(struct shake128_ctx *ctx);
+ void shake256_init(struct shake256_ctx *ctx);
+
+Data is then added with the appropriate update function, again one per
+algorithm::
+
+ void sha3_224_update(struct sha3_224_ctx *ctx,
+ const u8 *data, size_t len);
+ void sha3_256_update(struct sha3_256_ctx *ctx,
+ const u8 *data, size_t len);
+ void sha3_384_update(struct sha3_384_ctx *ctx,
+ const u8 *data, size_t len);
+ void sha3_512_update(struct sha3_512_ctx *ctx,
+ const u8 *data, size_t len);
+ void shake128_update(struct shake128_ctx *ctx,
+ const u8 *data, size_t len);
+ void shake256_update(struct shake256_ctx *ctx,
+ const u8 *data, size_t len);
+
+The update function may be called multiple times if need be to add
+non-contiguous data.
+
+For digest algorithms, the digest is finalised and extracted with the
+algorithm-specific function::
+
+ void sha3_224_final(struct sha3_224_ctx *ctx,
+ u8 out[SHA3_224_DIGEST_SIZE]);
+ void sha3_256_final(struct sha3_256_ctx *ctx,
+ u8 out[SHA3_256_DIGEST_SIZE]);
+ void sha3_384_final(struct sha3_384_ctx *ctx,
+ u8 out[SHA3_384_DIGEST_SIZE]);
+ void sha3_512_final(struct sha3_512_ctx *ctx,
+ u8 out[SHA3_512_DIGEST_SIZE]);
+
+which also explicitly clears the context. The amount of data extracted is
+determined by the type.
+
+
+Extendable-Output Functions
+---------------------------
+
+For XOFs, once the data has been added to a context, a variable amount of data
+may be extracted. This can be done by calling the appropriate squeeze
+function::
+
+ void shake128_squeeze(struct shake128_ctx *ctx, u8 *out, size_t out_len);
+ void shake256_squeeze(struct shake256_ctx *ctx, u8 *out, size_t out_len);
+
+and telling it how much data should be extracted. The squeeze function may be
+called multiple times but it will only append the domain separation suffix on
+the first invocation.
+
+Note that performing a number of squeezes, with the output laid consequitively
+in a buffer, gets exactly the same output as doing a single squeeze for the
+combined amount over the same buffer.
+
+Once all the desired output has been extracted, the context should be cleared
+with the clear function appropriate to the algorithm::
+
+ void shake128_clear(struct shake128_ctx *ctx);
+ void shake256_clear(struct shake256_ctx *ctx);
+
+
+Convenience API
+===============
+
+It only a single contiguous buffer of input needs to be added and only a single
+buffer of digest or XOF output is required, then a convenience API is provided
+that wraps all the required steps into a single function. There is one
+function for each algorithm supported::
+
+ void sha3_224(const u8 *in, size_t in_len, u8 out[SHA3_224_DIGEST_SIZE]);
+ void sha3_256(const u8 *in, size_t in_len, u8 out[SHA3_256_DIGEST_SIZE]);
+ void sha3_384(const u8 *in, size_t in_len, u8 out[SHA3_384_DIGEST_SIZE]);
+ void sha3_512(const u8 *in, size_t in_len, u8 out[SHA3_512_DIGEST_SIZE]);
+ void shake128(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+ void shake256(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+
+
+Internal API
+============
+
+There is a common internal API underlying all of this that may be used to build
+further algorithms or APIs as the engine in the same in all cases. The
+algorithm APIs all wrap the common context structure::
+
+ struct sha3_ctx {
+ struct sha3_state state;
+ u8 block_size;
+ u8 padding;
+ u8 absorb_offset;
+ u8 squeeze_offset;
+ bool end_marked;
+ };
+
+ struct sha3_state {
+ u64 st[SHA3_STATE_SIZE / 8];
+ };
+
+The fields are as follows:
+
+ * ``state.st``
+
+ An array of 25 64-bit state buckets that are used to hold the mathematical
+ state of the Keccak engine. Data is XOR'd onto part of this, the engine is
+ cranked and then the output is copied from this.
+
+ For the convenience of adding input and extract output from it, the array is
+ kept in little-endian order most of the time, but is byteswapped to
+ host-endian in order to perform the Keccak function and then byteswapped
+ back again. On an LE machine, the byteswapping is a no-op.
+
+ * ``block_size``
+
+ The size of the block of state that can be updated or extracted at a time.
+ This is related to the algorithm size and is analogous to the "rate" in the
+ algorithm definition.
+
+ * ``padding``
+
+ The terminating byte to add when finalising the stat. This may differ
+ between algorithms.
+
+ * ``absorb_offset``
+
+ This tracks which is the next byte of state to be updated; when it hits
+ ``block_size``, the engine is cranked and this is reset to 0.
+
+ * ``squeeze_offset``
+
+ This tracks which is the next byte of state to be extracted; similar to
+ ``partial``, when it hits ``block_size``, if more output is requested, the
+ engine is cranked to generate more and this is reset to 0.
+
+ * ``end_marked``
+
+ This is set to true when the domain separation suffix and any padding have
+ been appended to the state to prevent multiple squeezings from XOF
+ algorithms from re-appending this.
+
+Note that the size of the digest is *not* included here as that's only needed
+at finalisation time for digest algorithms and can be supplied then. It is not
+relevant to XOFs.
+
+To make use of the context, the following internal functions are provided::
+
+ void sha3_update(struct sha3_ctx *ctx, const u8 *data, size_t len);
+ void sha3_squeeze(struct sha3_ctx *ctx, u8 *out, size_t out_len);
+ void sha3_clear(struct sha3_ctx *ctx);
+
+These allow data to be appended to/absorbed into the state, output to be
+extracted/squeezed from the state and for the state to be cleared. Note that
+there is no "final" function, per se, but that can be constructed by squeezing
+and clearing.
+
+
+Testing
+-------
+
+The sha3 module does a basic sanity test on initialisation, but there is also a
+kunit test module available.
+
+
+References
+==========
+
+[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
+
+
+
+API Function Reference
+======================
+
+.. kernel-doc:: crypto/lib/sha3.c
+.. kernel-doc:: include/crypto/sha3.h
diff --git a/include/crypto/sha3.h b/include/crypto/sha3.h
index 41e1b83a6d91..a54117cb1546 100644
--- a/include/crypto/sha3.h
+++ b/include/crypto/sha3.h
@@ -1,11 +1,14 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Common values for SHA-3 algorithms
+ *
+ * See also Documentation/crypto/sha3.rst
*/
#ifndef __CRYPTO_SHA3_H__
#define __CRYPTO_SHA3_H__
#include <linux/types.h>
+#include <linux/string.h>
#define SHA3_224_DIGEST_SIZE (224 / 8)
#define SHA3_224_BLOCK_SIZE (200 - 2 * SHA3_224_DIGEST_SIZE)
@@ -23,6 +26,14 @@
#define SHA3_512_BLOCK_SIZE (200 - 2 * SHA3_512_DIGEST_SIZE)
#define SHA3_512_EXPORT_SIZE SHA3_STATE_SIZE + SHA3_512_BLOCK_SIZE + 1
+/* SHAKE128 and SHAKE256 actually have variable output size, but this is
+ * used to calculate the block size/rate analogously to the above..
+ */
+#define SHAKE128_DEFAULT_SIZE (128 / 8)
+#define SHAKE128_BLOCK_SIZE (200 - 2 * SHAKE128_DEFAULT_SIZE)
+#define SHAKE256_DEFAULT_SIZE (256 / 8)
+#define SHAKE256_BLOCK_SIZE (200 - 2 * SHAKE256_DEFAULT_SIZE)
+
#define SHA3_STATE_SIZE 200
struct shash_desc;
@@ -31,6 +42,426 @@ struct sha3_state {
u64 st[SHA3_STATE_SIZE / 8];
};
+/*
+ * The SHA3 context structure and state buffer.
+ *
+ * To avoid the need to byteswap when adding input and extracting output from
+ * the state array, the state array is kept in little-endian order most of the
+ * time, but is byteswapped to host-endian in order to perform the Keccak
+ * function and then byteswapped back again after. On a LE machine, the
+ * byteswap step is a no-op.
+ */
+struct sha3_ctx {
+ struct sha3_state state;
+ u8 block_size; /* Block size in bytes */
+ u8 padding; /* Padding byte */
+ u8 absorb_offset; /* Next state byte to absorb into */
+ u8 squeeze_offset; /* Next state byte to extract */
+ bool end_marked; /* T if end marker inserted */
+};
+
int crypto_sha3_init(struct shash_desc *desc);
-#endif
+/**
+ * sha3_clear() - Explicitly clear the entire context
+ * @ctx: the context to clear
+ *
+ * Explicitly clear the entire context, including the type parameters; after
+ * this, the context must be fully initialized again.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_clear(struct sha3_ctx *ctx)
+{
+ memzero_explicit(ctx, sizeof(*ctx));
+}
+
+void sha3_update(struct sha3_ctx *ctx, const u8 *data, size_t len);
+void sha3_squeeze(struct sha3_ctx *ctx, u8 *out, size_t out_len);
+
+/*
+ * Context wrapper for SHA3-224.
+ */
+struct sha3_224_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * sha3_224_init() - Set a SHA3 context for SHA3-224
+ * @ctx: the context to initialize
+ *
+ * Initialize a SHA3 context for the production of a SHA3-224 digest of a
+ * message.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_224_init(struct sha3_224_ctx *ctx)
+{
+ *ctx = (struct sha3_224_ctx){
+ .ctx.block_size = SHA3_224_BLOCK_SIZE,
+ .ctx.padding = 0x06,
+ };
+}
+
+/**
+ * sha3_224_update() - Update a SHA3-224 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the hash, performing
+ * the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_224_update(struct sha3_224_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * sha3_224_final() - Finalise a SHA3-224 hash and extract the digest
+ * @ctx: The context to finalise; must have been initialized
+ * @out: Where to write the resulting message digest
+ *
+ * Finish the computation of a SHA3-224 hash and perform the "Keccak sponge
+ * squeezing" phase. The digest is written to @out buffer and the context will
+ * be completely zeroed out.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_224_final(struct sha3_224_ctx *ctx, u8 out[SHA3_224_DIGEST_SIZE])
+{
+ sha3_squeeze(&ctx->ctx, out, SHA3_224_DIGEST_SIZE);
+ sha3_clear(&ctx->ctx);
+}
+
+/*
+ * Context wrapper for SHA3-256.
+ */
+struct sha3_256_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * sha3_256_init() - Set a SHA3 context for SHA3-256
+ * @ctx: the context to initialize
+ *
+ * Initialize a SHA3 context for the production of a SHA3-256 digest of a
+ * message.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_256_init(struct sha3_256_ctx *ctx)
+{
+ *ctx = (struct sha3_256_ctx){
+ .ctx.block_size = SHA3_256_BLOCK_SIZE,
+ .ctx.padding = 0x06,
+ };
+}
+
+/**
+ * sha3_256_update() - Update a SHA3-256 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the hash, performing
+ * the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_256_update(struct sha3_256_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * sha3_256_final() - Finalise a SHA3-256 hash and extract the digest
+ * @ctx: The context to finalise; must have been initialized
+ * @out: Where to write the resulting message digest
+ *
+ * Finish the computation of a SHA3-256 hash and perform the "Keccak sponge
+ * squeezing" phase. The digest is written to @out buffer and the context will
+ * be completely zeroed out.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_256_final(struct sha3_256_ctx *ctx, u8 out[SHA3_256_DIGEST_SIZE])
+{
+ sha3_squeeze(&ctx->ctx, out, SHA3_256_DIGEST_SIZE);
+ sha3_clear(&ctx->ctx);
+}
+
+/*
+ * Context wrapper for SHA3-384.
+ */
+struct sha3_384_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * sha3_384_init() - Set a SHA3 context for SHA3-384
+ * @ctx: the context to initialize
+ *
+ * Initialize a SHA3 context for the production of a SHA3-384 digest of a
+ * message.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_384_init(struct sha3_384_ctx *ctx)
+{
+ *ctx = (struct sha3_384_ctx){
+ .ctx.block_size = SHA3_384_BLOCK_SIZE,
+ .ctx.padding = 0x06,
+ };
+}
+
+/**
+ * sha3_384_update() - Update a SHA3-384 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the hash, performing
+ * the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_384_update(struct sha3_384_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * sha3_384_final() - Finalise a SHA3-384 hash and extract the digest
+ * @ctx: The context to finalise; must have been initialized
+ * @out: Where to write the resulting message digest
+ *
+ * Finish the computation of a SHA3-384 hash and perform the "Keccak sponge
+ * squeezing" phase. The digest is written to @out buffer and the context will
+ * be completely zeroed out.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_384_final(struct sha3_384_ctx *ctx, u8 out[SHA3_384_DIGEST_SIZE])
+{
+ sha3_squeeze(&ctx->ctx, out, SHA3_384_DIGEST_SIZE);
+ sha3_clear(&ctx->ctx);
+}
+
+/*
+ * Context wrapper for SHA3-512.
+ */
+struct sha3_512_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * sha3_512_init() - Set a SHA3 context for SHA3-512
+ * @ctx: the context to initialize
+ *
+ * Initialize a SHA3 context for the production of a SHA3-512 digest of a
+ * message.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_512_init(struct sha3_512_ctx *ctx)
+{
+ *ctx = (struct sha3_512_ctx){
+ .ctx.block_size = SHA3_512_BLOCK_SIZE,
+ .ctx.padding = 0x06,
+ };
+}
+
+/**
+ * sha3_512_update() - Update a SHA3-512 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the hash, performing
+ * the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_512_update(struct sha3_512_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * sha3_512_final() - Finalise a SHA3-512 hash and extract the digest
+ * @ctx: The context to finalise; must have been initialized
+ * @out: Where to write the resulting message digest
+ *
+ * Finish the computation of a SHA3-512 hash and perform the "Keccak sponge
+ * squeezing" phase. The digest is written to @out buffer and the context will
+ * be completely zeroed out.
+ *
+ * Context: Any context.
+ */
+static inline void sha3_512_final(struct sha3_512_ctx *ctx, u8 out[SHA3_512_DIGEST_SIZE])
+{
+ sha3_squeeze(&ctx->ctx, out, SHA3_512_DIGEST_SIZE);
+ sha3_clear(&ctx->ctx);
+}
+
+/*
+ * Context wrapper for SHAKE128.
+ */
+struct shake128_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * shake128_init() - Set a SHA3 context for SHAKE128
+ * @ctx: The context to initialize
+ *
+ * Initialize a SHA3 context for the production of SHAKE128 output generation
+ * from a message. The sha3_squeeze() function can be used to extract an
+ * arbitrary amount of data from the context.
+ *
+ * Context: Any context.
+ */
+static inline void shake128_init(struct shake128_ctx *ctx)
+{
+ *ctx = (struct shake128_ctx){
+ .ctx.block_size = SHAKE128_BLOCK_SIZE,
+ .ctx.padding = 0x1f,
+ };
+}
+
+/**
+ * shake128_update() - Update a SHAKE128 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the XOF state,
+ * performing the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void shake128_update(struct shake128_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * shake128_squeeze() - Finalize a SHAKE128 digest of any type and extract the digest
+ * @ctx: the context to finalize; must have been initialized
+ * @out: Where to write the resulting message digest
+ * @out_size: The amount of digest to extract to @out in bytes
+ *
+ * Finish the computation of a SHAKE128 XOF and perform the "Keccak sponge
+ * squeezing" phase. @out_size amount of digest is written to @out buffer.
+ *
+ * This may be called multiple times to extract continuations of the digest.
+ * Note that, a number of consecutive squeezes laid end-to-end will yield the
+ * same output as one big squeeze generating the same total amount of output.
+ *
+ * Context: Any context.
+ */
+static inline void shake128_squeeze(struct shake128_ctx *ctx, u8 *out, size_t out_size)
+{
+ return sha3_squeeze(&ctx->ctx, out, out_size);
+}
+
+/**
+ * shake128_clear() - Explicitly clear the entire SHAKE128 context
+ * @ctx: the context to clear
+ *
+ * Explicitly clear the entire context; after this, the context must be
+ * initialized again.
+ *
+ * Context: Any context.
+ */
+static inline void shake128_clear(struct shake128_ctx *ctx)
+{
+ sha3_clear(&ctx->ctx);
+}
+
+/*
+ * Context wrapper for SHAKE256.
+ */
+struct shake256_ctx {
+ struct sha3_ctx ctx;
+};
+
+/**
+ * shake256_init() - Set a SHA3 context for SHAKE256
+ * @ctx: The context to initialize
+ *
+ * Initialize a SHA3 context for the production of SHAKE256 output generation
+ * from a message. The sha3_squeeze() function can be used to extract an
+ * arbitrary amount of data from the context.
+ *
+ * Context: Any context.
+ */
+static inline void shake256_init(struct shake256_ctx *ctx)
+{
+ *ctx = (struct shake256_ctx){
+ .ctx.block_size = SHAKE256_BLOCK_SIZE,
+ .ctx.padding = 0x1f,
+ };
+}
+
+/**
+ * shake256_update() - Update a SHAKE256 hash with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to add data to the XOF state,
+ * performing the "keccak sponge absorbing" phase.
+ *
+ * Context: Any context.
+ */
+static inline void shake256_update(struct shake256_ctx *ctx, const u8 *data, size_t len)
+{
+ return sha3_update(&ctx->ctx, data, len);
+}
+
+/**
+ * shake256_squeeze() - Finalize a SHAKE256 digest of any type and extract the digest
+ * @ctx: the context to finalize; must have been initialized
+ * @out: Where to write the resulting message digest
+ * @out_size: The amount of digest to extract to @out in bytes
+ *
+ * Finish the computation of a SHAKE256 XOF and perform the "Keccak sponge
+ * squeezing" phase. @out_size amount of digest is written to @out buffer.
+ *
+ * This may be called multiple times to extract continuations of the digest.
+ * Note that, a number of consecutive squeezes laid end-to-end will yield the
+ * same output as one big squeeze generating the same total amount of output.
+ *
+ * Context: Any context.
+ */
+static inline void shake256_squeeze(struct shake256_ctx *ctx, u8 *out, size_t out_size)
+{
+ return sha3_squeeze(&ctx->ctx, out, out_size);
+}
+
+/**
+ * shake256_clear() - Explicitly clear the entire SHAKE256 context
+ * @ctx: the context to clear
+ *
+ * Explicitly clear the entire context; after this, the context must be
+ * initialized again.
+ *
+ * Context: Any context.
+ */
+static inline void shake256_clear(struct shake256_ctx *ctx)
+{
+ sha3_clear(&ctx->ctx);
+}
+
+void sha3_224(const u8 *in, size_t in_len, u8 out[SHA3_224_DIGEST_SIZE]);
+void sha3_256(const u8 *in, size_t in_len, u8 out[SHA3_256_DIGEST_SIZE]);
+void sha3_384(const u8 *in, size_t in_len, u8 out[SHA3_384_DIGEST_SIZE]);
+void sha3_512(const u8 *in, size_t in_len, u8 out[SHA3_512_DIGEST_SIZE]);
+void shake128(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+void shake256(const u8 *in, size_t in_len, u8 *out, size_t out_len);
+
+#endif /* __CRYPTO_SHA3_H__ */
diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index eea17e36a22b..1caf3fbe24bf 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -184,6 +184,13 @@ config CRYPTO_LIB_SHA512_ARCH
default y if SPARC64
default y if X86_64
+config CRYPTO_LIB_SHA3
+ tristate
+ help
+ The SHA3 library functions.
+ Select this if your module uses any of these functions from
+ <crypto/sha3.h>.
+
config CRYPTO_LIB_SM3
tristate
diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
index bded351aeace..b7fa51bfeebb 100644
--- a/lib/crypto/Makefile
+++ b/lib/crypto/Makefile
@@ -268,6 +268,12 @@ endif # CONFIG_CRYPTO_LIB_SHA512_ARCH
################################################################################
+#obj-$(CONFIG_CRYPTO_LIB_SHA3) += libsha3.o
+#libsha3-y := sha3.o
+obj-$(CONFIG_CRYPTO_SHA3) += sha3.o
+
+################################################################################
+
obj-$(CONFIG_MPILIB) += mpi/
obj-$(CONFIG_CRYPTO_SELFTESTS_FULL) += simd.o
diff --git a/lib/crypto/sha3.c b/lib/crypto/sha3.c
new file mode 100644
index 000000000000..5f847a5eecdc
--- /dev/null
+++ b/lib/crypto/sha3.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Cryptographic API.
+ *
+ * SHA-3, as specified in
+ * https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
+ *
+ * SHA-3 code by Jeff Garzik <jeff@garzik.org>
+ * Ard Biesheuvel <ard.biesheuvel@linaro.org>
+ * David Howells <dhowells@redhat.com>
+ *
+ * See also Documentation/crypto/sha3.rst
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <crypto/sha3.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/unaligned.h>
+
+/*
+ * On some 32-bit architectures, such as h8300, GCC ends up using over 1 KB of
+ * stack if the round calculation gets inlined into the loop in
+ * sha3_keccakf_rounds_generic(). On the other hand, on 64-bit architectures
+ * with plenty of [64-bit wide] general purpose registers, not inlining it
+ * severely hurts performance. So let's use 64-bitness as a heuristic to
+ * decide whether to inline or not.
+ */
+#ifdef CONFIG_64BIT
+#define SHA3_INLINE inline
+#else
+#define SHA3_INLINE noinline
+#endif
+
+#define SHA3_KECCAK_ROUNDS 24
+
+static const u64 sha3_keccakf_rndc[24] = {
+ 0x0000000000000001ULL, 0x0000000000008082ULL, 0x800000000000808aULL,
+ 0x8000000080008000ULL, 0x000000000000808bULL, 0x0000000080000001ULL,
+ 0x8000000080008081ULL, 0x8000000000008009ULL, 0x000000000000008aULL,
+ 0x0000000000000088ULL, 0x0000000080008009ULL, 0x000000008000000aULL,
+ 0x000000008000808bULL, 0x800000000000008bULL, 0x8000000000008089ULL,
+ 0x8000000000008003ULL, 0x8000000000008002ULL, 0x8000000000000080ULL,
+ 0x000000000000800aULL, 0x800000008000000aULL, 0x8000000080008081ULL,
+ 0x8000000000008080ULL, 0x0000000080000001ULL, 0x8000000080008008ULL
+};
+
+/*
+ * Perform a single round of Keccak mixing.
+ */
+static SHA3_INLINE void sha3_keccakf_one_round_generic(struct sha3_state *state)
+{
+ u64 *st = state->st;
+ u64 t[5], tt, bc[5];
+
+ /* Theta */
+ bc[0] = st[0] ^ st[5] ^ st[10] ^ st[15] ^ st[20];
+ bc[1] = st[1] ^ st[6] ^ st[11] ^ st[16] ^ st[21];
+ bc[2] = st[2] ^ st[7] ^ st[12] ^ st[17] ^ st[22];
+ bc[3] = st[3] ^ st[8] ^ st[13] ^ st[18] ^ st[23];
+ bc[4] = st[4] ^ st[9] ^ st[14] ^ st[19] ^ st[24];
+
+ t[0] = bc[4] ^ rol64(bc[1], 1);
+ t[1] = bc[0] ^ rol64(bc[2], 1);
+ t[2] = bc[1] ^ rol64(bc[3], 1);
+ t[3] = bc[2] ^ rol64(bc[4], 1);
+ t[4] = bc[3] ^ rol64(bc[0], 1);
+
+ st[0] ^= t[0];
+
+ /* Rho Pi */
+ tt = st[1];
+ st[ 1] = rol64(st[ 6] ^ t[1], 44);
+ st[ 6] = rol64(st[ 9] ^ t[4], 20);
+ st[ 9] = rol64(st[22] ^ t[2], 61);
+ st[22] = rol64(st[14] ^ t[4], 39);
+ st[14] = rol64(st[20] ^ t[0], 18);
+ st[20] = rol64(st[ 2] ^ t[2], 62);
+ st[ 2] = rol64(st[12] ^ t[2], 43);
+ st[12] = rol64(st[13] ^ t[3], 25);
+ st[13] = rol64(st[19] ^ t[4], 8);
+ st[19] = rol64(st[23] ^ t[3], 56);
+ st[23] = rol64(st[15] ^ t[0], 41);
+ st[15] = rol64(st[ 4] ^ t[4], 27);
+ st[ 4] = rol64(st[24] ^ t[4], 14);
+ st[24] = rol64(st[21] ^ t[1], 2);
+ st[21] = rol64(st[ 8] ^ t[3], 55);
+ st[ 8] = rol64(st[16] ^ t[1], 45);
+ st[16] = rol64(st[ 5] ^ t[0], 36);
+ st[ 5] = rol64(st[ 3] ^ t[3], 28);
+ st[ 3] = rol64(st[18] ^ t[3], 21);
+ st[18] = rol64(st[17] ^ t[2], 15);
+ st[17] = rol64(st[11] ^ t[1], 10);
+ st[11] = rol64(st[ 7] ^ t[2], 6);
+ st[ 7] = rol64(st[10] ^ t[0], 3);
+ st[10] = rol64( tt ^ t[1], 1);
+
+ /* Chi */
+ bc[ 0] = ~st[ 1] & st[ 2];
+ bc[ 1] = ~st[ 2] & st[ 3];
+ bc[ 2] = ~st[ 3] & st[ 4];
+ bc[ 3] = ~st[ 4] & st[ 0];
+ bc[ 4] = ~st[ 0] & st[ 1];
+ st[ 0] ^= bc[ 0];
+ st[ 1] ^= bc[ 1];
+ st[ 2] ^= bc[ 2];
+ st[ 3] ^= bc[ 3];
+ st[ 4] ^= bc[ 4];
+
+ bc[ 0] = ~st[ 6] & st[ 7];
+ bc[ 1] = ~st[ 7] & st[ 8];
+ bc[ 2] = ~st[ 8] & st[ 9];
+ bc[ 3] = ~st[ 9] & st[ 5];
+ bc[ 4] = ~st[ 5] & st[ 6];
+ st[ 5] ^= bc[ 0];
+ st[ 6] ^= bc[ 1];
+ st[ 7] ^= bc[ 2];
+ st[ 8] ^= bc[ 3];
+ st[ 9] ^= bc[ 4];
+
+ bc[ 0] = ~st[11] & st[12];
+ bc[ 1] = ~st[12] & st[13];
+ bc[ 2] = ~st[13] & st[14];
+ bc[ 3] = ~st[14] & st[10];
+ bc[ 4] = ~st[10] & st[11];
+ st[10] ^= bc[ 0];
+ st[11] ^= bc[ 1];
+ st[12] ^= bc[ 2];
+ st[13] ^= bc[ 3];
+ st[14] ^= bc[ 4];
+
+ bc[ 0] = ~st[16] & st[17];
+ bc[ 1] = ~st[17] & st[18];
+ bc[ 2] = ~st[18] & st[19];
+ bc[ 3] = ~st[19] & st[15];
+ bc[ 4] = ~st[15] & st[16];
+ st[15] ^= bc[ 0];
+ st[16] ^= bc[ 1];
+ st[17] ^= bc[ 2];
+ st[18] ^= bc[ 3];
+ st[19] ^= bc[ 4];
+
+ bc[ 0] = ~st[21] & st[22];
+ bc[ 1] = ~st[22] & st[23];
+ bc[ 2] = ~st[23] & st[24];
+ bc[ 3] = ~st[24] & st[20];
+ bc[ 4] = ~st[20] & st[21];
+ st[20] ^= bc[ 0];
+ st[21] ^= bc[ 1];
+ st[22] ^= bc[ 2];
+ st[23] ^= bc[ 3];
+ st[24] ^= bc[ 4];
+}
+
+static void sha3_keccakf_rounds_generic(struct sha3_state *state)
+{
+ for (int round = 0; round < SHA3_KECCAK_ROUNDS; round++) {
+ sha3_keccakf_one_round_generic(state);
+ /* Iota */
+ state->st[0] ^= sha3_keccakf_rndc[round];
+ }
+}
+
+/*
+ * Byteswap the state buckets to CPU-endian if we're not on a little-endian
+ * machine for the duration of the Keccak mixing function. Note that these
+ * loops are no-ops on LE machines and will be optimised away.
+ */
+static void sha3_keccakf_generic(struct sha3_state *state)
+{
+ for (int i = 0; i < ARRAY_SIZE(state->st); i++)
+ cpu_to_le64s(&state->st[i]);
+
+ sha3_keccakf_rounds_generic(state);
+
+ for (int i = 0; i < ARRAY_SIZE(state->st); i++)
+ le64_to_cpus(&state->st[i]);
+}
+
+static void sha3_absorb_block_generic(struct sha3_ctx *ctx, const u8 *data)
+{
+ struct sha3_state *state = &ctx->state;
+ size_t bsize = ctx->block_size;
+
+ for (size_t i = 0; i < bsize / 8; i++)
+ state->st[i] ^= get_unaligned((u64 *)(data + 8 * i));
+ sha3_keccakf_generic(state);
+}
+
+/*
+ * Perform rounds of XOR'ing whole blocks of data into the state buffer and
+ * then performing a keccak mix step.
+ */
+static void sha3_absorb_blocks_generic(struct sha3_ctx *ctx,
+ const u8 *data, size_t nblocks)
+{
+ do {
+ sha3_absorb_block_generic(ctx, data);
+ data += ctx->block_size;
+ } while (--nblocks);
+}
+
+#ifdef CONFIG_CRYPTO_LIB_SHA3_ARCH
+#include "sha3.h" /* $(SRCARCH)/sha3.h */
+#else
+#define sha3_keccakf sha3_keccakf_generic
+#define sha3_absorb_blocks sha3_absorb_blocks_generic
+#endif
+
+/*
+ * XOR in partial data that's insufficient to fill a whole block.
+ */
+static void sha3_absorb_xorle(struct sha3_ctx *ctx, const u8 *data,
+ size_t partial, size_t len)
+{
+ u8 *buf = (u8 *)ctx->state.st;
+
+ buf += partial;
+ for (size_t i = 0; i < len; i++)
+ *buf++ ^= *data++;
+}
+
+/**
+ * sha3_update() - Update a SHA3 context of any type with message data
+ * @ctx: the context to update; must have been initialized
+ * @data: the message data
+ * @len: the data length in bytes
+ *
+ * This can be called any number of times to perform the "keccak sponge
+ * absorbing" phase.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_update(struct sha3_ctx *ctx, const u8 *data, size_t len)
+{
+ size_t absorb_offset = ctx->absorb_offset;
+ size_t bsize = ctx->block_size;
+
+ WARN_ON_ONCE(ctx->end_marked);
+
+ if (absorb_offset && absorb_offset + len >= bsize) {
+ sha3_absorb_xorle(ctx, data, absorb_offset, bsize - absorb_offset);
+ len -= bsize - absorb_offset;
+ data += bsize - absorb_offset;
+ sha3_keccakf(&ctx->state);
+ ctx->absorb_offset = 0;
+ }
+
+ if (len >= bsize) {
+ size_t nblocks = len / bsize;
+
+ sha3_absorb_blocks(ctx, data, nblocks);
+ data += nblocks * bsize;
+ len -= nblocks * bsize;
+ }
+
+ if (len) {
+ sha3_absorb_xorle(ctx, data, ctx->absorb_offset, len);
+ ctx->absorb_offset += len;
+ }
+}
+EXPORT_SYMBOL_GPL(sha3_update);
+
+/**
+ * sha3_squeeze() - Finalize a SHA3 digest of any type and extract the digest
+ * @ctx: the context to finalize; must have been initialized
+ * @out: Where to write the resulting message digest
+ * @out_size: The amount of digest to extract to @out
+ *
+ * Finish the computation of a SHA3 message digest of any type and perform the
+ * "Keccak sponge squeezing" phase. @out_size amount of digest is written to
+ * @out buffer.
+ *
+ * This may be called multiple times to extract continuations of the digest.
+ * Note that, for example, two consecutive 16-byte squeezes laid end-to-end
+ * will yield the same as one 32-byte squeeze.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_squeeze(struct sha3_ctx *ctx, u8 *out, size_t out_size)
+{
+ size_t squeeze_offset = ctx->squeeze_offset;
+ size_t bsize = ctx->block_size;
+ u8 *p = (u8 *)ctx->state.st, end_marker = 0x80;
+
+ if (!ctx->end_marked) {
+ sha3_absorb_xorle(ctx, &ctx->padding, ctx->absorb_offset, 1);
+ sha3_absorb_xorle(ctx, &end_marker, bsize - 1, 1);
+ ctx->end_marked = true;
+ }
+
+ for (;;) {
+ if (squeeze_offset == 0)
+ sha3_keccakf(&ctx->state);
+
+ size_t part = umin(out_size, bsize - squeeze_offset);
+
+ if (part > 0) {
+ memcpy(out, p + squeeze_offset, part);
+ out_size -= part;
+ out += part;
+ squeeze_offset += part;
+ }
+ if (!out_size)
+ break;
+ if (squeeze_offset >= bsize)
+ squeeze_offset = 0;
+ }
+
+ ctx->squeeze_offset = squeeze_offset;
+}
+EXPORT_SYMBOL_GPL(sha3_squeeze);
+
+/**
+ * sha3_224() - Convenience wrapper to digest a simple buffer as SHA3-224
+ * @in: The data to be digested
+ * @in_len: The amount of data to be digested in bytes
+ * @out: The buffer into which the digest will be stored (size not checked)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHA-224, add the input
+ * data to it, finalise it, extract 28 bytes of digest and clear the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_224(const u8 *in, size_t in_len, u8 out[SHA3_224_DIGEST_SIZE])
+{
+ struct sha3_224_ctx ctx;
+
+ sha3_224_init(&ctx);
+ sha3_224_update(&ctx, in, in_len);
+ sha3_224_final(&ctx, out);
+}
+EXPORT_SYMBOL(sha3_224);
+
+/**
+ * sha3_256() - Convenience wrapper to digest a simple buffer as SHA3-256
+ * @in: The data to be digested
+ * @in_len: The amount of data to be digested in bytes
+ * @out: The buffer into which the digest will be stored (size not checked)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHA-256, add the input
+ * data to it, finalise it, extract 32 bytes of digest and clear the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_256(const u8 *in, size_t in_len, u8 out[SHA3_256_DIGEST_SIZE])
+{
+ struct sha3_256_ctx ctx;
+
+ sha3_256_init(&ctx);
+ sha3_256_update(&ctx, in, in_len);
+ sha3_256_final(&ctx, out);
+}
+EXPORT_SYMBOL(sha3_256);
+
+/**
+ * sha3_384() - Convenience wrapper to digest a simple buffer as SHA3-384
+ * @in: The data to be digested
+ * @in_len: The amount of data to be digested in bytes
+ * @out: The buffer into which the digest will be stored (size not checked)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHA-384, add the input
+ * data to it, finalise it, extract 48 bytes of digest and clear the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_384(const u8 *in, size_t in_len, u8 out[SHA3_384_DIGEST_SIZE])
+{
+ struct sha3_384_ctx ctx;
+
+ sha3_384_init(&ctx);
+ sha3_384_update(&ctx, in, in_len);
+ sha3_384_final(&ctx, out);
+}
+EXPORT_SYMBOL(sha3_384);
+
+/**
+ * sha3_512() - Convenience wrapper to digest a simple buffer as SHA3-512
+ * @in: The data to be digested in bytes
+ * @in_len: The amount of data to be digested in bytes
+ * @out: The buffer into which the digest will be stored (size not checked)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHA-512, add the input
+ * data to it, finalise it, extract 64 bytes of digest and clear the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void sha3_512(const u8 *in, size_t in_len, u8 out[SHA3_512_DIGEST_SIZE])
+{
+ struct sha3_512_ctx ctx;
+
+ sha3_512_init(&ctx);
+ sha3_512_update(&ctx, in, in_len);
+ sha3_512_final(&ctx, out);
+}
+EXPORT_SYMBOL(sha3_512);
+
+/**
+ * shake128() - Convenience wrapper to apply SHAKE128 to a simple buffer
+ * @in: The input data to be used
+ * @in_len: The amount of input data in bytes
+ * @out: The buffer in which to store the output
+ * @out_len: The amount of output to store in bytes (variable length)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHAKE128, add the input
+ * data to it, finalise it, extract the requested amount of output and clear
+ * the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void shake128(const u8 *in, size_t in_len, u8 *out, size_t out_len)
+{
+ struct shake128_ctx ctx;
+
+ shake128_init(&ctx);
+ shake128_update(&ctx, in, in_len);
+ shake128_squeeze(&ctx, out, out_len);
+ shake128_clear(&ctx);
+}
+EXPORT_SYMBOL(shake128);
+
+/**
+ * shake256() - Convenience wrapper to apply SHAKE256 to a simple buffer
+ * @in: The input data to be used
+ * @in_len: The amount of input data in bytes
+ * @out: The buffer in which to store the output
+ * @out_len: The amount of output to store in bytes (variable length)
+ *
+ * Convenience wrapper to initialise a SHA3 context for SHAKE128, add the input
+ * data to it, finalise it, extract the requested amount of output and clear
+ * the context.
+ *
+ * Context: May use the FPU/Vector unit registers.
+ */
+void shake256(const u8 *in, size_t in_len, u8 *out, size_t out_len)
+{
+ struct shake256_ctx ctx;
+
+ shake256_init(&ctx);
+ shake256_update(&ctx, in, in_len);
+ shake256_squeeze(&ctx, out, out_len);
+ shake256_clear(&ctx);
+}
+EXPORT_SYMBOL(shake256);
+
+/*
+ * Do a quick test using SHAKE256 and a 200 byte digest.
+ */
+static const u8 sha3_sample[] __initconst =
+ "The quick red fox jumped over the lazy brown dog!\n"
+ "The quick red fox jumped over the lazy brown dog!\n"
+ "The quick red fox jumped over the lazy brown dog!\n"
+ "The quick red fox jumped over the lazy brown dog!\n";
+
+static const u8 sha3_sample_shake256_200[] __initconst = {
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* Write-before guard */
+ 0xab, 0x06, 0xd4, 0xf9, 0x8b, 0xfd, 0xb2, 0xc4, 0xfe, 0xf1, 0xcc, 0xe2,
+ 0x40, 0x45, 0xdd, 0x15, 0xcb, 0xdd, 0x02, 0x8d, 0xb7, 0x9f, 0x1e, 0x67,
+ 0xd6, 0x7f, 0x98, 0x5e, 0x1b, 0x19, 0xf8, 0x01, 0x43, 0x82, 0xcb, 0xd8,
+ 0x5d, 0x21, 0x64, 0xa8, 0x80, 0xc9, 0x22, 0xe5, 0x07, 0xaf, 0xe2, 0x5d,
+ 0xcd, 0xc6, 0x23, 0x36, 0x2b, 0xc7, 0xc7, 0x7d, 0x09, 0x9d, 0x68, 0x05,
+ 0xe4, 0x62, 0x63, 0x1b, 0x67, 0xbc, 0xf8, 0x95, 0x07, 0xd2, 0xe4, 0xd0,
+ 0xba, 0xa2, 0x67, 0xf5, 0xe3, 0x15, 0xbc, 0x85, 0xa1, 0x50, 0xd6, 0x6f,
+ 0x6f, 0xd4, 0x54, 0x4c, 0x3f, 0x4f, 0xe5, 0x1f, 0xb7, 0x00, 0x27, 0xfc,
+ 0x15, 0x33, 0xc2, 0xf9, 0xb3, 0x4b, 0x9e, 0x81, 0xe5, 0x96, 0xbe, 0x05,
+ 0x6c, 0xac, 0xf9, 0x9f, 0x65, 0x36, 0xbb, 0x11, 0x47, 0x6d, 0xf6, 0x8f,
+ 0x9f, 0xa2, 0x77, 0x37, 0x3b, 0x18, 0x77, 0xcf, 0x65, 0xc5, 0xa1, 0x7e,
+ 0x2c, 0x0e, 0x71, 0xf0, 0x4d, 0x18, 0x67, 0xb9, 0xc4, 0x8c, 0x64, 0x3b,
+ 0x4b, 0x45, 0xea, 0x16, 0xb2, 0x4a, 0xc5, 0xf5, 0x85, 0xdc, 0xd2, 0xd9,
+ 0x13, 0x77, 0xb3, 0x19, 0xd9, 0x8c, 0x9f, 0x28, 0xe7, 0x64, 0x91, 0x0f,
+ 0x6f, 0x32, 0xbf, 0xa8, 0xa8, 0xa3, 0xff, 0x99, 0x0e, 0x0b, 0x62, 0x50,
+ 0xf8, 0x3a, 0xc2, 0xf5, 0x98, 0x21, 0xeb, 0x9d, 0xe8, 0x45, 0xf4, 0x46,
+ 0x1e, 0x8b, 0xbd, 0x10, 0x59, 0x2c, 0x87, 0xe2,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* Write-after guard */
+};
+
+static int __init sha3_mod_init(void)
+{
+#define out_len 200
+ u8 out[8 + out_len + 8] = {};
+
+#ifdef sha3_mod_init_arch
+ sha3_mod_init_arch();
+#endif
+
+ BUILD_BUG_ON(sizeof(out) != sizeof(sha3_sample_shake256_200));
+
+ shake256(sha3_sample, sizeof(sha3_sample) - 1, out + 8, out_len);
+
+ if (memcmp(out, sha3_sample_shake256_200,
+ sizeof(sha3_sample_shake256_200)) != 0) {
+ pr_err("SHAKE256(200) failed\n");
+ for (size_t i = 0; i < out_len;) {
+ size_t part = min(out_len - i, 32);
+
+ pr_err("%*phN\n", (int)part, out + i);
+ i += part;
+ }
+ return -EBADMSG;
+ }
+ return 0;
+}
+subsys_initcall(sha3_mod_init);
+
+static void __exit sha3_mod_exit(void)
+{
+}
+module_exit(sha3_mod_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("SHA-3 Secure Hash Algorithm");
^ permalink raw reply related
* [PATCH v6 02/17] arm64/sha3: Rename conflicting functions
From: David Howells @ 2025-10-17 14:42 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel, Catalin Marinas, Will Deacon,
linux-arm-kernel
In-Reply-To: <20251017144311.817771-1-dhowells@redhat.com>
Rename the arm64 sha3_* functions to have an "arm64_" prefix to avoid
conflict with generic code.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Jason A. Donenfeld <Jason@zx2c4.com>
cc: Ard Biesheuvel <ardb@kernel.org>
cc: Catalin Marinas <catalin.marinas@arm.com>
cc: Will Deacon <will@kernel.org>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: Stephan Mueller <smueller@chronox.de>
cc: linux-crypto@vger.kernel.org
cc: linux-arm-kernel@lists.infradead.org
---
arch/arm64/crypto/sha3-ce-glue.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/crypto/sha3-ce-glue.c b/arch/arm64/crypto/sha3-ce-glue.c
index b4f1001046c9..426d8044535a 100644
--- a/arch/arm64/crypto/sha3-ce-glue.c
+++ b/arch/arm64/crypto/sha3-ce-glue.c
@@ -31,7 +31,7 @@ MODULE_ALIAS_CRYPTO("sha3-512");
asmlinkage int sha3_ce_transform(u64 *st, const u8 *data, int blocks,
int md_len);
-static int sha3_update(struct shash_desc *desc, const u8 *data,
+static int arm64_sha3_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
struct sha3_state *sctx = shash_desc_ctx(desc);
@@ -55,8 +55,8 @@ static int sha3_update(struct shash_desc *desc, const u8 *data,
return len;
}
-static int sha3_finup(struct shash_desc *desc, const u8 *src, unsigned int len,
- u8 *out)
+static int arm64_sha3_finup(struct shash_desc *desc, const u8 *src, unsigned int len,
+ u8 *out)
{
struct sha3_state *sctx = shash_desc_ctx(desc);
struct crypto_shash *tfm = desc->tfm;
@@ -90,8 +90,8 @@ static int sha3_finup(struct shash_desc *desc, const u8 *src, unsigned int len,
static struct shash_alg algs[] = { {
.digestsize = SHA3_224_DIGEST_SIZE,
.init = crypto_sha3_init,
- .update = sha3_update,
- .finup = sha3_finup,
+ .update = arm64_sha3_update,
+ .finup = arm64_sha3_finup,
.descsize = SHA3_STATE_SIZE,
.base.cra_name = "sha3-224",
.base.cra_driver_name = "sha3-224-ce",
@@ -102,8 +102,8 @@ static struct shash_alg algs[] = { {
}, {
.digestsize = SHA3_256_DIGEST_SIZE,
.init = crypto_sha3_init,
- .update = sha3_update,
- .finup = sha3_finup,
+ .update = arm64_sha3_update,
+ .finup = arm64_sha3_finup,
.descsize = SHA3_STATE_SIZE,
.base.cra_name = "sha3-256",
.base.cra_driver_name = "sha3-256-ce",
@@ -114,8 +114,8 @@ static struct shash_alg algs[] = { {
}, {
.digestsize = SHA3_384_DIGEST_SIZE,
.init = crypto_sha3_init,
- .update = sha3_update,
- .finup = sha3_finup,
+ .update = arm64_sha3_update,
+ .finup = arm64_sha3_finup,
.descsize = SHA3_STATE_SIZE,
.base.cra_name = "sha3-384",
.base.cra_driver_name = "sha3-384-ce",
@@ -126,8 +126,8 @@ static struct shash_alg algs[] = { {
}, {
.digestsize = SHA3_512_DIGEST_SIZE,
.init = crypto_sha3_init,
- .update = sha3_update,
- .finup = sha3_finup,
+ .update = arm64_sha3_update,
+ .finup = arm64_sha3_finup,
.descsize = SHA3_STATE_SIZE,
.base.cra_name = "sha3-512",
.base.cra_driver_name = "sha3-512-ce",
^ permalink raw reply related
* [PATCH v6 01/17] s390/sha3: Rename conflicting functions
From: David Howells @ 2025-10-17 14:42 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel, Harald Freudenberger, Holger Dengler,
linux-s390
In-Reply-To: <20251017144311.817771-1-dhowells@redhat.com>
Rename the s390 sha3_* functions to have an "s390_" prefix to avoid
conflict with generic code.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-By: Harald Freudenberger <freude@linux.ibm.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Jason A. Donenfeld <Jason@zx2c4.com>
cc: Ard Biesheuvel <ardb@kernel.org>
cc: Holger Dengler <dengler@linux.ibm.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: Stephan Mueller <smueller@chronox.de>
cc: linux-crypto@vger.kernel.org
cc: linux-s390@vger.kernel.org
---
arch/s390/crypto/sha3_256_s390.c | 26 +++++++++++++-------------
arch/s390/crypto/sha3_512_s390.c | 26 +++++++++++++-------------
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/s390/crypto/sha3_256_s390.c b/arch/s390/crypto/sha3_256_s390.c
index 03bb4f4bab70..fd5ecae60a57 100644
--- a/arch/s390/crypto/sha3_256_s390.c
+++ b/arch/s390/crypto/sha3_256_s390.c
@@ -19,7 +19,7 @@
#include "sha.h"
-static int sha3_256_init(struct shash_desc *desc)
+static int s390_sha3_256_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
@@ -32,7 +32,7 @@ static int sha3_256_init(struct shash_desc *desc)
return 0;
}
-static int sha3_256_export(struct shash_desc *desc, void *out)
+static int s390_sha3_256_export(struct shash_desc *desc, void *out)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
union {
@@ -50,7 +50,7 @@ static int sha3_256_export(struct shash_desc *desc, void *out)
return 0;
}
-static int sha3_256_import(struct shash_desc *desc, const void *in)
+static int s390_sha3_256_import(struct shash_desc *desc, const void *in)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
union {
@@ -68,22 +68,22 @@ static int sha3_256_import(struct shash_desc *desc, const void *in)
return 0;
}
-static int sha3_224_import(struct shash_desc *desc, const void *in)
+static int s390_sha3_224_import(struct shash_desc *desc, const void *in)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
- sha3_256_import(desc, in);
+ s390_sha3_256_import(desc, in);
sctx->func = CPACF_KIMD_SHA3_224;
return 0;
}
static struct shash_alg sha3_256_alg = {
.digestsize = SHA3_256_DIGEST_SIZE, /* = 32 */
- .init = sha3_256_init,
+ .init = s390_sha3_256_init,
.update = s390_sha_update_blocks,
.finup = s390_sha_finup,
- .export = sha3_256_export,
- .import = sha3_256_import,
+ .export = s390_sha3_256_export,
+ .import = s390_sha3_256_import,
.descsize = S390_SHA_CTX_SIZE,
.statesize = SHA3_STATE_SIZE,
.base = {
@@ -96,22 +96,22 @@ static struct shash_alg sha3_256_alg = {
}
};
-static int sha3_224_init(struct shash_desc *desc)
+static int s390_sha3_224_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
- sha3_256_init(desc);
+ s390_sha3_256_init(desc);
sctx->func = CPACF_KIMD_SHA3_224;
return 0;
}
static struct shash_alg sha3_224_alg = {
.digestsize = SHA3_224_DIGEST_SIZE,
- .init = sha3_224_init,
+ .init = s390_sha3_224_init,
.update = s390_sha_update_blocks,
.finup = s390_sha_finup,
- .export = sha3_256_export, /* same as for 256 */
- .import = sha3_224_import, /* function code different! */
+ .export = s390_sha3_256_export, /* same as for 256 */
+ .import = s390_sha3_224_import, /* function code different! */
.descsize = S390_SHA_CTX_SIZE,
.statesize = SHA3_STATE_SIZE,
.base = {
diff --git a/arch/s390/crypto/sha3_512_s390.c b/arch/s390/crypto/sha3_512_s390.c
index a5c9690eecb1..f4b52a3a0433 100644
--- a/arch/s390/crypto/sha3_512_s390.c
+++ b/arch/s390/crypto/sha3_512_s390.c
@@ -18,7 +18,7 @@
#include "sha.h"
-static int sha3_512_init(struct shash_desc *desc)
+static int s390_sha3_512_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
@@ -31,7 +31,7 @@ static int sha3_512_init(struct shash_desc *desc)
return 0;
}
-static int sha3_512_export(struct shash_desc *desc, void *out)
+static int s390_sha3_512_export(struct shash_desc *desc, void *out)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
union {
@@ -49,7 +49,7 @@ static int sha3_512_export(struct shash_desc *desc, void *out)
return 0;
}
-static int sha3_512_import(struct shash_desc *desc, const void *in)
+static int s390_sha3_512_import(struct shash_desc *desc, const void *in)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
union {
@@ -67,22 +67,22 @@ static int sha3_512_import(struct shash_desc *desc, const void *in)
return 0;
}
-static int sha3_384_import(struct shash_desc *desc, const void *in)
+static int s390_sha3_384_import(struct shash_desc *desc, const void *in)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
- sha3_512_import(desc, in);
+ s390_sha3_512_import(desc, in);
sctx->func = CPACF_KIMD_SHA3_384;
return 0;
}
static struct shash_alg sha3_512_alg = {
.digestsize = SHA3_512_DIGEST_SIZE,
- .init = sha3_512_init,
+ .init = s390_sha3_512_init,
.update = s390_sha_update_blocks,
.finup = s390_sha_finup,
- .export = sha3_512_export,
- .import = sha3_512_import,
+ .export = s390_sha3_512_export,
+ .import = s390_sha3_512_import,
.descsize = S390_SHA_CTX_SIZE,
.statesize = SHA3_STATE_SIZE,
.base = {
@@ -97,22 +97,22 @@ static struct shash_alg sha3_512_alg = {
MODULE_ALIAS_CRYPTO("sha3-512");
-static int sha3_384_init(struct shash_desc *desc)
+static int s390_sha3_384_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
- sha3_512_init(desc);
+ s390_sha3_512_init(desc);
sctx->func = CPACF_KIMD_SHA3_384;
return 0;
}
static struct shash_alg sha3_384_alg = {
.digestsize = SHA3_384_DIGEST_SIZE,
- .init = sha3_384_init,
+ .init = s390_sha3_384_init,
.update = s390_sha_update_blocks,
.finup = s390_sha_finup,
- .export = sha3_512_export, /* same as for 512 */
- .import = sha3_384_import, /* function code different! */
+ .export = s390_sha3_512_export, /* same as for 512 */
+ .import = s390_sha3_384_import, /* function code different! */
.descsize = S390_SHA_CTX_SIZE,
.statesize = SHA3_STATE_SIZE,
.base = {
^ permalink raw reply related
* [PATCH v6 00/17] lib/crypto: Move SHA3 to lib/crypto, add SHAKE* and add ML-DSA signing
From: David Howells @ 2025-10-17 14:42 UTC (permalink / raw)
To: Eric Biggers
Cc: David Howells, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Petr Pavlu, Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel
Hi Eric, Herbert, et al.,
Here's a set of patches does the following:
Firstly, SHA-3 is implemented in lib/crypto and SHAKE* support is added:
(1) Renames s390 and arm64 sha3_* functions to avoid name collisions.
(2) Copies the core of SHA3 support from crypto/ to lib/crypto/.
(3) Simplifies the internal code to maintain the buffer in little endian
form, thereby simplifying the update and extraction code which don't
then need to worry about this. Instead, the state buffer is
byteswapped before and after.
(4) Moves the Iota transform into the function with the rest of the
transforms.
(5) Adds SHAKE128 and SHAKE256 support (needed for ML-DSA).
(6) Adds a kunit test for SHA3 in lib/crypto/tests/.
(7) Adds API documentation for SHA3.
Note that only the generic code is moved across; the asm-optimised stuff is
not touched as I'm not familiar with that.
Secondly, SHA-3 crypto/ support is added, though this turns out not to be
necessary for ML-DSA:
(8) Make the jitterentropy random number generator use lib/crypto sha-3.
I can't get it to work with crypto/sha3_generic when that is modified
to use lib/crypto. It looks like there's some race that prevents the
kernel from booting, but I can't tell what and it's really hard to
debug. However, it works fine with lib/crypto/sha3 directly.
(9) Make crypto/sha3_generic use lib/crypto/sha3.
(10) Add SHAKE-128 and SHAKE-256 crypto_sig support, generating 16-byte and
32-byte fixed output respectively. The XOF features aren't available
through this.
Thirdly, add ML-DSA support and allow module signing to use it. This needs
some more code cleanup, but it does work. OpenSSL doesn't support
CMS_NOATTR with ML-DSA, unfortunately, so that has to be turned off for
ML-DSA.
(11) Add ML-DSA signing and signature verification code, extracted from
Stephan Mueller's Leancrypto project. This needs more code cleanup,
but I think it's worth posting it now. I also suspect I should remove
the in-kernel signature generation side of things and only keep the
verification side. It is accessed through crypto_sig.
(12) Add ML-DSA keypair generation code. I don't think we want this.
(13) Add a kunit test in three installments (due to size) to add some
testing for the three different levels of ML-DSA (44, 65 and 87).
(14) Modify PKCS#7 support to allow kernel module signatures to carry
authenticatedAttributes as OpenSSL refuses to let them be opted out of
for ML-DSA (CMS_NOATTR). This adds an extra digest calculation to the
process.
(15) Modify PKCS#7 to pass the authenticatedAttributes directly to the
ML-DSA algorithm rather than passing over a digest as is done with RSA
as ML-DSA wants to do its own hashing and will add other stuff into
the hash. We could use hashML-DSA or an external mu instead, but they
aren't standardised for CMS yet.
(16) Add support to the PKCS#7 and X.509 parsers for ML-DSA.
(17) Modify sign-file to handle OpenSSL not permitting CMS_NOATTR with
ML-DSA.
(18) Allow SHA-3 algorithms, including SHAKE256, to be used for the message
digest and add ML-DSA to the choice of algorithm with which to sign.
With that, ML-DSA signing appears to work.
This is based on Eric's libcrypto-next branch.
The patches can also be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-pqc
David
Changes
=======
ver #6)
- Added a patch to make the jitterentropy RNG use lib/sha3.
- Added back the crypto/sha3_generic changes.
- Added ML-DSA implementation (still needs more cleanup).
- Added kunit test for ML-DSA.
- Modified PKCS#7 to accommodate ML-DSA.
- Modified PKCS#7 and X.509 to allow ML-DSA to be specified and used.
- Modified sign-file to not use CMS_NOATTR with ML-DSA.
- Allowed SHA3 and SHAKE* algorithms for module signing default.
- Allowed ML-DSA-{44,65,87} to be selected as the module signing default.
ver #5)
- Fix gen-hash-testvecs.py to correctly handle algo names that contain a
dash.
- Fix gen-hash-testvecs.py to not generate HMAC for SHA3-* or SHAKE* as
these don't currently have HMAC variants implemented.
- Fix algo names to be correct.
- Fix kunit module description as it now tests all SHA3 variants.
ver #4)
- Fix a couple of arm64 build problems.
- Doc fixes:
- Fix the description of the algorithm to be closer to the NIST spec's
terminology.
- Don't talk of finialising the context for XOFs.
- Don't say "Return: None".
- Declare the "Context" to be "Any context" and make no mention of the
fact that it might use the FPU.
- Change "initialise" to "initialize".
- Don't warn that the context is relatively large for stack use.
- Use size_t for size parameters/variables.
- Make the module_exit unconditional.
- Dropped the crypto/ dir-affecting patches for the moment.
ver #3)
- Renamed conflicting arm64 functions.
- Made a separate wrapper API for each algorithm in the family.
- Removed sha3_init(), sha3_reinit() and sha3_final().
- Removed sha3_ctx::digest_size.
- Renamed sha3_ctx::partial to sha3_ctx::absorb_offset.
- Refer to the output of SHAKE* as "output" not "digest".
- Moved the Iota transform into the one-round function.
- Made sha3_update() warn if called after sha3_squeeze().
- Simplified the module-load test to not do update after squeeze.
- Added Return: and Context: kdoc statements and expanded the kdoc
headers.
- Added an API description document.
- Overhauled the kunit tests.
- Only have one kunit test.
- Only call the general hash tester on one algo.
- Add separate simple cursory checks for the other algos.
- Add resqueezing tests.
- Add some NIST example tests.
- Changed crypto/sha3_generic to use this
- Added SHAKE128/256 to crypto/sha3_generic and crypto/testmgr
- Folded struct sha3_state into struct sha3_ctx.
ver #2)
- Simplify the endianness handling.
- Rename sha3_final() to sha3_squeeze() and don't clear the context at the
end as it's permitted to continue calling sha3_final() to extract
continuations of the digest (needed by ML-DSA).
- Don't reapply the end marker to the hash state in continuation
sha3_squeeze() unless sha3_update() gets called again (needed by
ML-DSA).
- Give sha3_squeeze() the amount of digest to produce as a parameter
rather than using ctx->digest_size and don't return the amount digested.
- Reimplement sha3_final() as a wrapper around sha3_squeeze() that
extracts ctx->digest_size amount of digest and then zeroes out the
context. The latter is necessary to avoid upsetting
hash-test-template.h.
- Provide a sha3_reinit() function to clear the state, but to leave the
parameters that indicate the hash properties unaffected, allowing for
reuse.
- Provide a sha3_set_digestsize() function to change the size of the
digest to be extracted by sha3_final(). sha3_squeeze() takes a
parameter for this instead.
- Don't pass the digest size as a parameter to shake128/256_init() but
rather default to 128/256 bits as per the function name.
- Provide a sha3_clear() function to zero out the context.
David Howells (17):
s390/sha3: Rename conflicting functions
arm64/sha3: Rename conflicting functions
lib/crypto: Add SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128,
SHAKE256
lib/crypto: Move the SHA3 Iota transform into the single round
function
lib/crypto: Add SHA3 kunit tests
crypto/jitterentropy: Use lib/crypto/sha3
crypto/sha3: Use lib/crypto/sha3
crypto/sha3: Add SHAKE128/256 support
crypto: SHAKE tests
crypto: Add ML-DSA/Dilithium support
crypto: Add ML-DSA/Dilithium keypair generation support
crypto: Add ML-DSA-44 pure rejection test vectors as a kunit test
crypto: Add ML-DSA-65 pure rejection test vectors as a kunit test
crypto: Add ML-DSA-87 pure rejection test vectors as a kunit test
pkcs7: Allow the signing algo to calculate the digest itself
pkcs7, x509: Add ML-DSA support
modsign: Enable ML-DSA module signing
Documentation/admin-guide/module-signing.rst | 15 +-
Documentation/crypto/index.rst | 1 +
Documentation/crypto/sha3.rst | 237 +
arch/arm64/crypto/sha3-ce-glue.c | 47 +-
arch/s390/crypto/sha3_256_s390.c | 26 +-
arch/s390/crypto/sha3_512_s390.c | 26 +-
certs/Kconfig | 24 +
certs/Makefile | 3 +
crypto/Kconfig | 1 +
crypto/Makefile | 1 +
crypto/asymmetric_keys/pkcs7_parser.c | 19 +-
crypto/asymmetric_keys/pkcs7_verify.c | 52 +-
crypto/asymmetric_keys/public_key.c | 7 +
crypto/asymmetric_keys/x509_cert_parser.c | 24 +
crypto/jitterentropy-kcapi.c | 100 +-
crypto/jitterentropy.c | 7 +-
crypto/jitterentropy.h | 8 +-
crypto/ml_dsa/Kconfig | 32 +
crypto/ml_dsa/Makefile | 20 +
crypto/ml_dsa/dilithium.h | 804 ++
crypto/ml_dsa/dilithium_44.c | 33 +
crypto/ml_dsa/dilithium_44.h | 412 +
crypto/ml_dsa/dilithium_65.c | 33 +
crypto/ml_dsa/dilithium_65.h | 412 +
crypto/ml_dsa/dilithium_87.c | 33 +
crypto/ml_dsa/dilithium_87.h | 412 +
crypto/ml_dsa/dilithium_api.c | 821 ++
crypto/ml_dsa/dilithium_debug.h | 80 +
crypto/ml_dsa/dilithium_ntt.c | 89 +
crypto/ml_dsa/dilithium_ntt.h | 35 +
crypto/ml_dsa/dilithium_pack.h | 285 +
crypto/ml_dsa/dilithium_pct.h | 53 +
crypto/ml_dsa/dilithium_poly.c | 586 +
crypto/ml_dsa/dilithium_poly.h | 190 +
crypto/ml_dsa/dilithium_poly_c.h | 149 +
crypto/ml_dsa/dilithium_poly_common.h | 35 +
crypto/ml_dsa/dilithium_polyvec.h | 363 +
crypto/ml_dsa/dilithium_polyvec_c.h | 114 +
.../dilithium_pure_rejection_vectors_44.h | 812 ++
.../dilithium_pure_rejection_vectors_65.h | 8290 ++++++++++++
.../dilithium_pure_rejection_vectors_87.h | 10761 ++++++++++++++++
crypto/ml_dsa/dilithium_reduce.h | 108 +
crypto/ml_dsa/dilithium_rounding.c | 128 +
crypto/ml_dsa/dilithium_rounding.h | 45 +
crypto/ml_dsa/dilithium_selftest.c | 183 +
crypto/ml_dsa/dilithium_service_helpers.h | 99 +
crypto/ml_dsa/dilithium_sig.c | 404 +
crypto/ml_dsa/dilithium_signature_c.c | 198 +
crypto/ml_dsa/dilithium_signature_c.h | 60 +
crypto/ml_dsa/dilithium_signature_helper.c | 110 +
crypto/ml_dsa/dilithium_signature_impl.h | 1033 ++
crypto/ml_dsa/dilithium_type.h | 281 +
crypto/ml_dsa/dilithium_zetas.c | 67 +
crypto/ml_dsa/fips_mode.h | 45 +
crypto/ml_dsa/signature_domain_separation.c | 213 +
crypto/ml_dsa/signature_domain_separation.h | 33 +
crypto/ml_dsa/small_stack_support.h | 40 +
crypto/sha3_generic.c | 241 +-
crypto/testmgr.c | 14 +
crypto/testmgr.h | 59 +
include/crypto/algapi.h | 2 +-
include/crypto/public_key.h | 1 +
include/crypto/sha3.h | 433 +-
include/linux/oid_registry.h | 5 +
kernel/module/Kconfig | 5 +
lib/crypto/Kconfig | 7 +
lib/crypto/Makefile | 6 +
lib/crypto/sha3.c | 511 +
lib/crypto/tests/Kconfig | 11 +
lib/crypto/tests/Makefile | 1 +
lib/crypto/tests/sha3_kunit.c | 342 +
lib/crypto/tests/sha3_testvecs.h | 231 +
scripts/crypto/gen-hash-testvecs.py | 10 +-
scripts/sign-file.c | 26 +-
74 files changed, 30050 insertions(+), 354 deletions(-)
create mode 100644 Documentation/crypto/sha3.rst
create mode 100644 crypto/ml_dsa/Kconfig
create mode 100644 crypto/ml_dsa/Makefile
create mode 100644 crypto/ml_dsa/dilithium.h
create mode 100644 crypto/ml_dsa/dilithium_44.c
create mode 100644 crypto/ml_dsa/dilithium_44.h
create mode 100644 crypto/ml_dsa/dilithium_65.c
create mode 100644 crypto/ml_dsa/dilithium_65.h
create mode 100644 crypto/ml_dsa/dilithium_87.c
create mode 100644 crypto/ml_dsa/dilithium_87.h
create mode 100644 crypto/ml_dsa/dilithium_api.c
create mode 100644 crypto/ml_dsa/dilithium_debug.h
create mode 100644 crypto/ml_dsa/dilithium_ntt.c
create mode 100644 crypto/ml_dsa/dilithium_ntt.h
create mode 100644 crypto/ml_dsa/dilithium_pack.h
create mode 100644 crypto/ml_dsa/dilithium_pct.h
create mode 100644 crypto/ml_dsa/dilithium_poly.c
create mode 100644 crypto/ml_dsa/dilithium_poly.h
create mode 100644 crypto/ml_dsa/dilithium_poly_c.h
create mode 100644 crypto/ml_dsa/dilithium_poly_common.h
create mode 100644 crypto/ml_dsa/dilithium_polyvec.h
create mode 100644 crypto/ml_dsa/dilithium_polyvec_c.h
create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_44.h
create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_65.h
create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_87.h
create mode 100644 crypto/ml_dsa/dilithium_reduce.h
create mode 100644 crypto/ml_dsa/dilithium_rounding.c
create mode 100644 crypto/ml_dsa/dilithium_rounding.h
create mode 100644 crypto/ml_dsa/dilithium_selftest.c
create mode 100644 crypto/ml_dsa/dilithium_service_helpers.h
create mode 100644 crypto/ml_dsa/dilithium_sig.c
create mode 100644 crypto/ml_dsa/dilithium_signature_c.c
create mode 100644 crypto/ml_dsa/dilithium_signature_c.h
create mode 100644 crypto/ml_dsa/dilithium_signature_helper.c
create mode 100644 crypto/ml_dsa/dilithium_signature_impl.h
create mode 100644 crypto/ml_dsa/dilithium_type.h
create mode 100644 crypto/ml_dsa/dilithium_zetas.c
create mode 100644 crypto/ml_dsa/fips_mode.h
create mode 100644 crypto/ml_dsa/signature_domain_separation.c
create mode 100644 crypto/ml_dsa/signature_domain_separation.h
create mode 100644 crypto/ml_dsa/small_stack_support.h
create mode 100644 lib/crypto/sha3.c
create mode 100644 lib/crypto/tests/sha3_kunit.c
create mode 100644 lib/crypto/tests/sha3_testvecs.h
^ permalink raw reply
* Re: [PATCH 2/2] module: Simplify warning on positive returns from module_init()
From: Petr Pavlu @ 2025-10-17 12:06 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel
In-Reply-To: <20251013-module-warn-ret-v1-2-ab65b41af01f@intel.com>
On 10/13/25 6:26 PM, Lucas De Marchi wrote:
> It should now be rare to trigger this warning - it doesn't need to be so
> verbose. Make it follow the usual style in the module loading code.
>
> For the same reason, drop the dump_stack().
>
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 1/2] module: Override -EEXISTS module return
From: Petr Pavlu @ 2025-10-17 12:04 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel
In-Reply-To: <20251013-module-warn-ret-v1-1-ab65b41af01f@intel.com>
On 10/13/25 6:26 PM, Lucas De Marchi wrote:
> The -EEXIST errno is reserved by the module loading functionality. When
> userspace calls [f]init_module(), it expects a -EEXIST to mean that the
> module is already loaded in the kernel. If module_init() returns it,
> that is not true anymore.
>
> Add a warning and override the return code to workaround modules
> currently returning the wrong code. It's expected that they eventually
> migrate to a better suited error.
>
> Closes: https://lore.kernel.org/all/aKLzsAX14ybEjHfJ@orbyte.nwl.cc/
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> kernel/module/main.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b261849362..74ff87b13c517 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
> if (mod->init != NULL)
> ret = do_one_initcall(mod->init);
> if (ret < 0) {
> + if (ret == -EEXIST) {
> + pr_warn("%s: init suspiciously returned -EEXIST: Overriding with -EBUSY\n",
> + mod->name);
> + ret = -EBUSY;
> + }
> goto fail_free_freeinit;
> }
> if (ret > 0) {
>
I assume you intentionally omitted the "(reserved for loaded modules)"
part from my previous suggestion [1] to keep the error message short.
Looks ok to me then.
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
[1] https://lore.kernel.org/linux-modules/ce7f293c-d9f9-4137-bcad-8cc492d34773@suse.com/
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH] docs: ABI: sysfs-module: list all taint flags
From: Petr Pavlu @ 2025-10-17 11:38 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, linux-kernel, linux-modules
In-Reply-To: <20251015221348.1125295-1-rdunlap@infradead.org>
On 10/16/25 12:13 AM, Randy Dunlap wrote:
> The list of module taint flags has not been updated lately as the
> taint flags list grows. Instead of trying to keep multiple lists
> updated, just refer to the list of kernel taint flags since they are
> the same.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: linux-modules@vger.kernel.org
> ---
> Documentation/ABI/testing/sysfs-module | 10 ++--------
> Documentation/admin-guide/tainted-kernels.rst | 2 ++
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> --- linux-next-20251014.orig/Documentation/ABI/testing/sysfs-module
> +++ linux-next-20251014/Documentation/ABI/testing/sysfs-module
> @@ -52,14 +52,8 @@ What: /sys/module/*/taint
> Date: Jan 2012
> KernelVersion: 3.3
> Contact: Kay Sievers <kay.sievers@vrfy.org>
> -Description: Module taint flags:
> - == =====================
> - P proprietary module
> - O out-of-tree module
> - F force-loaded module
> - C staging driver module
> - E unsigned module
> - == =====================
> +Description: Module taint flags: same as the kernel taint flags.
> + See: :ref:`taint_flags` in Documentation/admin-guide/tainted-kernels.rst
The module taint flags that can appear in /sys/module/*/taint are
a subset of the kernel taint flags. By looking at the calls to
add_taint_module(), they are as follows:
Present:
TAINT_PROPRIETARY_MODULE
TAINT_OOT_MODULE
TAINT_FORCED_MODULE
TAINT_CRAP
TAINT_UNSIGNED_MODULE
Missing:
TAINT_LIVEPATCH
TAINT_TEST
+ potentially TEST_AUX.
Since this text specifically documents what can appear in
/sys/module/*/taint, I think we should still maintain a list of these
flags for accuracy.
Additionally, Documentation/admin-guide/tainted-kernels.rst provides
taint descriptions for the kernel as a whole, which can be misleading
for individual modules. For instance, for TAINT_LIVEPATCH, the document
says "kernel has been live patched", but in the context of
/sys/module/*/taint, it means "this is a livepatch module".
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v17 01/47] llist: move llist_{head,node} definition to types.h
From: Arnd Bergmann @ 2025-10-16 7:59 UTC (permalink / raw)
To: Byungchul Park
Cc: Mathieu Desnoyers, Greg Kroah-Hartman, linux-kernel, kernel_team,
Linus Torvalds, Damien Le Moal, linux-ide, Andreas Dilger,
linux-ext4, Ingo Molnar, Peter Zijlstra, Will Deacon,
Thomas Gleixner, Steven Rostedt, Joel Fernandes, Sasha Levin,
Daniel Vetter, duyuyang, Johannes Berg, Tejun Heo,
Theodore Ts'o, Matthew Wilcox, Dave Chinner, Amir Goldstein,
kernel-team, linux-mm, Andrew Morton, Michal Hocko, Minchan Kim,
Johannes Weiner, vdavydov.dev, SeongJae Park, jglisse,
Dennis Zhou, Christoph Lameter, Pekka Enberg, David Rientjes,
Vlastimil Babka, ngupta, linux-block, Josef Bacik, linux-fsdevel,
Jan Kara, Jeff Layton, Dan Williams, Christoph Hellwig,
Darrick J. Wong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, Gwan-gyeong Mun,
max.byungchul.park, Boqun Feng, Waiman Long, yunseong.kim, ysk,
Yeoreum Yun, Netdev, Matthew Brost, her0gyugyu, Jonathan Corbet,
Catalin Marinas, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Sumit Semwal, gustavo,
Christian König, Andi Shyti, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan,
Luis Chamberlain, Petr Pavlu, da.gomez, Sami Tolvanen,
Paul E. McKenney, Frederic Weisbecker, neeraj.upadhyay,
joelagnelf, Josh Triplett, Uladzislau Rezki (Sony), Lai Jiangshan,
qiang.zhang, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Benjamin Segall, Mel Gorman, Valentin Schneider, Chuck Lever,
neil, okorniev, Dai Ngo, Tom Talpey, trondmy, Anna Schumaker,
Kees Cook, Sebastian Andrzej Siewior, Clark Williams,
Mark Rutland, ada.coupriediaz, kristina.martsenko, Kefeng Wang,
Mark Brown, Kevin Brodsky, David Woodhouse, Shakeel Butt,
Alexei Starovoitov, Zi Yan, Yu Zhao, Baolin Wang, usamaarif642,
joel.granados, Wei Yang, Geert Uytterhoeven, tim.c.chen, linux,
Alexander Shishkin, lillian, Huacai Chen, francesco,
guoweikang.kernel, link, Josh Poimboeuf, Masahiro Yamada,
Christian Brauner, Thomas Weißschuh, Oleg Nesterov,
Mateusz Guzik, Andrii Nakryiko, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
Linux-Arch, linux-modules, rcu, linux-nfs, linux-rt-devel
In-Reply-To: <20251016004640.GB2948@system.software.com>
On Thu, Oct 16, 2025, at 02:46, Byungchul Park wrote:
> On Fri, Oct 03, 2025 at 01:19:33AM +0200, Arnd Bergmann wrote:
>> On Thu, Oct 2, 2025, at 15:53, Mathieu Desnoyers wrote:
>> > On 2025-10-02 04:24, Greg KH wrote:
>> >> On Thu, Oct 02, 2025 at 05:12:01PM +0900, Byungchul Park wrote:
>> Maybe a shared linux/list_types.h would work, to specifically
>
> I found a way to resolve my issue, but I thought it's good idea
> regardless of my issue and took a quick look. However, it seems like
> there's an overwhelming amount of work since it might require to replace
> all the existing include <linux/types.h> for use of list things with the
> new one :-).
I don't think it's that bad, since almost every header ends up
including linux/list.h indirectly at the moment.
A little bit of scripting to find the headers that reference
'struct list_head' but don't also include linux/list.h reveals
this relatively short set that would need to include the new
header:
> include/keys/asymmetric-parser.h
> include/linux/dynamic_debug.h
> include/linux/genalloc.h
> include/linux/gpio/machine.h
> include/linux/hiddev.h
> include/linux/iio/iio-opaque.h
> include/linux/iio/sysfs.h
> include/linux/input/touch-overlay.h
> include/linux/irq_poll.h
> include/linux/iscsi_boot_sysfs.h
> include/linux/kcore.h
> include/linux/kcsan-checks.h
> include/linux/kcsan.h
> include/linux/lockdep_types.h
> include/linux/logic_pio.h
> include/linux/maple.h
> include/linux/mfd/iqs62x.h
> include/linux/mlx5/macsec.h
> include/linux/mount.h
> include/linux/mtd/map.h
> include/linux/mtd/nand-qpic-common.h
> include/linux/mtd/partitions.h
> include/linux/mutex_types.h
> include/linux/nfs_fs_i.h
> include/linux/of_iommu.h
> include/linux/parport_pc.h
> include/linux/pinctrl/pinctrl.h
> include/linux/plist_types.h
> include/linux/pm_wakeup.h
> include/linux/reboot-mode.h
> include/linux/shm.h
> include/linux/smpboot.h
> include/linux/sunrpc/xprtmultipath.h
> include/linux/usb/audio.h
> include/linux/workqueue_types.h
> include/linux/zpool.h
> include/net/bluetooth/hci_sync.h
> include/net/bluetooth/l2cap.h
> include/net/bluetooth/rfcomm.h
> include/net/dcbnl.h
> include/sound/i2c.h
> include/sound/soc-jack.h
> include/target/iscsi/iscsi_transport.h
> include/video/udlfb.h
A lot of these don't have any #include statements at all,
which indicates that they expect to only be included in
places where the dependencies are already visible.
Arnd
^ permalink raw reply
* Re: [PATCH v17 01/47] llist: move llist_{head,node} definition to types.h
From: Byungchul Park @ 2025-10-16 0:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mathieu Desnoyers, Greg Kroah-Hartman, linux-kernel, kernel_team,
Linus Torvalds, Damien Le Moal, linux-ide, Andreas Dilger,
linux-ext4, Ingo Molnar, Peter Zijlstra, Will Deacon,
Thomas Gleixner, Steven Rostedt, Joel Fernandes, Sasha Levin,
Daniel Vetter, duyuyang, Johannes Berg, Tejun Heo,
Theodore Ts'o, Matthew Wilcox, Dave Chinner, Amir Goldstein,
kernel-team, linux-mm, Andrew Morton, Michal Hocko, Minchan Kim,
Johannes Weiner, vdavydov.dev, SeongJae Park, jglisse,
Dennis Zhou, Christoph Lameter, Pekka Enberg, David Rientjes,
Vlastimil Babka, ngupta, linux-block, Josef Bacik, linux-fsdevel,
Jan Kara, Jeff Layton, Dan Williams, Christoph Hellwig,
Darrick J. Wong, dri-devel, rodrigosiqueiramelo, melissa.srw,
hamohammed.sa, harry.yoo, chris.p.wilson, Gwan-gyeong Mun,
max.byungchul.park, Boqun Feng, Waiman Long, yunseong.kim, ysk,
Yeoreum Yun, Netdev, Matthew Brost, her0gyugyu, Jonathan Corbet,
Catalin Marinas, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Sumit Semwal, gustavo,
Christian König, Andi Shyti, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan,
Luis Chamberlain, Petr Pavlu, da.gomez, Sami Tolvanen,
Paul E. McKenney, Frederic Weisbecker, neeraj.upadhyay,
joelagnelf, Josh Triplett, Uladzislau Rezki (Sony), Lai Jiangshan,
qiang.zhang, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Benjamin Segall, Mel Gorman, Valentin Schneider, Chuck Lever,
neil, okorniev, Dai Ngo, Tom Talpey, trondmy, Anna Schumaker,
Kees Cook, Sebastian Andrzej Siewior, Clark Williams,
Mark Rutland, ada.coupriediaz, kristina.martsenko, Kefeng Wang,
Mark Brown, Kevin Brodsky, David Woodhouse, Shakeel Butt,
Alexei Starovoitov, Zi Yan, Yu Zhao, Baolin Wang, usamaarif642,
joel.granados, Wei Yang, Geert Uytterhoeven, tim.c.chen, linux,
Alexander Shishkin, lillian, Huacai Chen, francesco,
guoweikang.kernel, link, Josh Poimboeuf, Masahiro Yamada,
Christian Brauner, Thomas Weißschuh, Oleg Nesterov,
Mateusz Guzik, Andrii Nakryiko, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
Linux-Arch, linux-modules, rcu, linux-nfs, linux-rt-devel
In-Reply-To: <3bbe14af-ccdc-4c78-a7ca-d4ed39fa6b5d@app.fastmail.com>
On Fri, Oct 03, 2025 at 01:19:33AM +0200, Arnd Bergmann wrote:
> On Thu, Oct 2, 2025, at 15:53, Mathieu Desnoyers wrote:
> > On 2025-10-02 04:24, Greg KH wrote:
> >> On Thu, Oct 02, 2025 at 05:12:01PM +0900, Byungchul Park wrote:
> >>> llist_head and llist_node can be used by some other header files. For
> >>> example, dept for tracking dependencies uses llist in its header. To
> >>> avoid header dependency, move them to types.h.
> >>
> >> If you need llist in your code, then include llist.h. Don't force all
> >> types.h users to do so as there is not a dependency in types.h for
> >> llist.h.
> >>
> >> This patch shouldn't be needed as you are hiding "header dependency" for
> >> other files.
> >
> > I agree that moving this into a catch-all types.h is not what we should
> > aim for.
> >
> > However, it's a good practice to move the type declarations to a
> > separate header file, so code that only cares about type and not
> > implementation of static inline functions can include just that.
> >
> > Perhaps we can move struct llist_head and struct llist_node to a new
> > include/linux/llist_types.h instead ?
>
> We have around a dozen types of linked lists, and the most common
> two of them are currently defined in linux/types.h, while the
> rest of them are each defined in the same header as the inteface
> definition.
>
> Duplicating each of those headers by splitting out the trivial
> type definition doesn't quite seem right either, as we'd end
> up with even more headers that have to be included indirectly
> in each compilation unit.
>
> Maybe a shared linux/list_types.h would work, to specifically
I found a way to resolve my issue, but I thought it's good idea
regardless of my issue and took a quick look. However, it seems like
there's an overwhelming amount of work since it might require to replace
all the existing include <linux/types.h> for use of list things with the
new one :-).
Byungchul
> contain all the list_head variants that are meant to be included
> in larger structures?
>
> Arnd
^ permalink raw reply
* Re: [PATCH v17 01/47] llist: move llist_{head,node} definition to types.h
From: Byungchul Park @ 2025-10-16 0:38 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, kernel-team, linux-mm, akpm, mhocko,
minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg,
rientjes, vbabka, ngupta, linux-block, josef, linux-fsdevel, jack,
jlayton, dan.j.williams, hch, djwong, dri-devel,
rodrigosiqueiramelo, melissa.srw, hamohammed.sa, harry.yoo,
chris.p.wilson, gwan-gyeong.mun, max.byungchul.park, boqun.feng,
longman, yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost,
her0gyugyu, corbet, catalin.marinas, bp, dave.hansen, x86, hpa,
luto, sumit.semwal, gustavo, christian.koenig, andi.shyti, arnd,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu,
da.gomez, samitolvanen, paulmck, frederic, neeraj.upadhyay,
joelagnelf, josh, urezki, mathieu.desnoyers, jiangshanlai,
qiang.zhang, juri.lelli, vincent.guittot, dietmar.eggemann,
bsegall, mgorman, vschneid, chuck.lever, neil, okorniev, Dai.Ngo,
tom, trondmy, anna, kees, bigeasy, clrkwllms, mark.rutland,
ada.coupriediaz, kristina.martsenko, wangkefeng.wang, broonie,
kevin.brodsky, dwmw, shakeel.butt, ast, ziy, yuzhao, baolin.wang,
usamaarif642, joel.granados, richard.weiyang, geert+renesas,
tim.c.chen, linux, alexander.shishkin, lillian, chenhuacai,
francesco, guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel
In-Reply-To: <2025100230-grafted-alias-22a2@gregkh>
On Thu, Oct 02, 2025 at 10:24:41AM +0200, Greg KH wrote:
> On Thu, Oct 02, 2025 at 05:12:01PM +0900, Byungchul Park wrote:
> > llist_head and llist_node can be used by some other header files. For
> > example, dept for tracking dependencies uses llist in its header. To
> > avoid header dependency, move them to types.h.
>
> If you need llist in your code, then include llist.h. Don't force all
Eventually, I found out another way to avoid the dependency issue.
Thanks anyway for the feedback.
Byungchul
> types.h users to do so as there is not a dependency in types.h for
> llist.h.
>
> This patch shouldn't be needed as you are hiding "header dependency" for
> other files.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] docs: ABI: sysfs-module: list all taint flags
From: Randy Dunlap @ 2025-10-15 22:13 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
linux-modules
The list of module taint flags has not been updated lately as the
taint flags list grows. Instead of trying to keep multiple lists
updated, just refer to the list of kernel taint flags since they are
the same.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: linux-modules@vger.kernel.org
---
Documentation/ABI/testing/sysfs-module | 10 ++--------
Documentation/admin-guide/tainted-kernels.rst | 2 ++
2 files changed, 4 insertions(+), 8 deletions(-)
--- linux-next-20251014.orig/Documentation/ABI/testing/sysfs-module
+++ linux-next-20251014/Documentation/ABI/testing/sysfs-module
@@ -52,14 +52,8 @@ What: /sys/module/*/taint
Date: Jan 2012
KernelVersion: 3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
-Description: Module taint flags:
- == =====================
- P proprietary module
- O out-of-tree module
- F force-loaded module
- C staging driver module
- E unsigned module
- == =====================
+Description: Module taint flags: same as the kernel taint flags.
+ See: :ref:`taint_flags` in Documentation/admin-guide/tainted-kernels.rst
What: /sys/module/grant_table/parameters/free_per_iteration
Date: July 2023
--- linux-next-20251014.orig/Documentation/admin-guide/tainted-kernels.rst
+++ linux-next-20251014/Documentation/admin-guide/tainted-kernels.rst
@@ -76,6 +76,8 @@ which bits are set::
$ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
+.. _taint_flags:
+
Table for decoding tainted state
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH v2 10/10] module loader: enforce symbol import protection
From: kernel test robot @ 2025-10-14 7:34 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: llvm, oe-kbuild-all, arnd, linux-arch, linux-kbuild, linux-kernel,
linux-modules, mcgrof, nathan, nicolas.schier, samitolvanen,
sidnayyar, maennich, gprocida
In-Reply-To: <20251013153918.2206045-11-sidnayyar@google.com>
Hi Siddharth,
kernel test robot noticed the following build errors:
[auto build test ERROR on arnd-asm-generic/master]
[also build test ERROR on soc/for-next linus/master v6.18-rc1 next-20251013]
[cannot apply to mcgrof/modules-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Siddharth-Nayyar/define-kernel-symbol-flags/20251014-005305
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
patch link: https://lore.kernel.org/r/20251013153918.2206045-11-sidnayyar%40google.com
patch subject: [PATCH v2 10/10] module loader: enforce symbol import protection
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251014/202510141538.VZqnRzHh-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251014/202510141538.VZqnRzHh-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510141538.VZqnRzHh-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/module/main.c:1271:32: error: no member named 'sig_ok' in 'struct module'
1271 | if (fsa.is_protected && !mod->sig_ok) {
| ~~~ ^
1 error generated.
vim +1271 kernel/module/main.c
1228
1229 /* Resolve a symbol for this module. I.e. if we find one, record usage. */
1230 static const struct kernel_symbol *resolve_symbol(struct module *mod,
1231 const struct load_info *info,
1232 const char *name,
1233 char ownername[])
1234 {
1235 struct find_symbol_arg fsa = {
1236 .name = name,
1237 .gplok = !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)),
1238 .warn = true,
1239 };
1240 int err;
1241
1242 /*
1243 * The module_mutex should not be a heavily contended lock;
1244 * if we get the occasional sleep here, we'll go an extra iteration
1245 * in the wait_event_interruptible(), which is harmless.
1246 */
1247 sched_annotate_sleep();
1248 mutex_lock(&module_mutex);
1249 if (!find_symbol(&fsa))
1250 goto unlock;
1251
1252 if (fsa.license == GPL_ONLY)
1253 mod->using_gplonly_symbols = true;
1254
1255 if (!inherit_taint(mod, fsa.owner, name)) {
1256 fsa.sym = NULL;
1257 goto getname;
1258 }
1259
1260 if (!check_version(info, name, mod, fsa.crc)) {
1261 fsa.sym = ERR_PTR(-EINVAL);
1262 goto getname;
1263 }
1264
1265 err = verify_namespace_is_imported(info, fsa.sym, mod);
1266 if (err) {
1267 fsa.sym = ERR_PTR(err);
1268 goto getname;
1269 }
1270
> 1271 if (fsa.is_protected && !mod->sig_ok) {
1272 pr_warn("%s: Cannot use protected symbol %s\n",
1273 mod->name, name);
1274 fsa.sym = ERR_PTR(-EACCES);
1275 goto getname;
1276 }
1277
1278 err = ref_module(mod, fsa.owner);
1279 if (err) {
1280 fsa.sym = ERR_PTR(err);
1281 goto getname;
1282 }
1283
1284 getname:
1285 /* We must make copy under the lock if we failed to get ref. */
1286 strscpy(ownername, module_name(fsa.owner), MODULE_NAME_LEN);
1287 unlock:
1288 mutex_unlock(&module_mutex);
1289 return fsa.sym;
1290 }
1291
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v17 28/47] dept: add documentation for dept
From: Byungchul Park @ 2025-10-14 6:38 UTC (permalink / raw)
To: NeilBrown
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, jlayton, dan.j.williams, hch, djwong,
dri-devel, rodrigosiqueiramelo, melissa.srw, hamohammed.sa,
harry.yoo, chris.p.wilson, gwan-gyeong.mun, max.byungchul.park,
boqun.feng, longman, yunseong.kim, ysk, yeoreum.yun, netdev,
matthew.brost, her0gyugyu, corbet, catalin.marinas, bp,
dave.hansen, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, okorniev, Dai.Ngo, tom, trondmy, anna, kees, bigeasy,
clrkwllms, mark.rutland, ada.coupriediaz, kristina.martsenko,
wangkefeng.wang, broonie, kevin.brodsky, dwmw, shakeel.butt, ast,
ziy, yuzhao, baolin.wang, usamaarif642, joel.granados,
richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel
In-Reply-To: <176042183810.1793333.13639772065939276568@noble.neil.brown.name>
On Tue, Oct 14, 2025 at 05:03:58PM +1100, NeilBrown wrote:
> On Mon, 13 Oct 2025, Byungchul Park wrote:
> > On Fri, Oct 03, 2025 at 04:55:14PM +1000, NeilBrown wrote:
> > > On Thu, 02 Oct 2025, Byungchul Park wrote:
> > > > This document describes the concept and APIs of dept.
> > > >
> > >
> > > Thanks for the documentation. I've been trying to understand it.
> >
> > You're welcome. Feel free to ask me if you have any questions.
> >
> > > > +How DEPT works
> > > > +--------------
> > > > +
> > > > +Let's take a look how DEPT works with the 1st example in the section
> > > > +'Limitation of lockdep'.
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + folio_lock B
> > > > + folio_lock B <- DEADLOCK
> > > > + mutex_lock A <- DEADLOCK
> > > > + folio_unlock B
> > > > + folio_unlock B
> > > > + mutex_unlock A
> > > > + mutex_unlock A
> > > > +
> > > > +Adding comments to describe DEPT's view in terms of wait and event:
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + /* wait for A */
> > > > + folio_lock B
> > > > + /* wait for A */
> > > > + /* start event A context */
> > > > +
> > > > + folio_lock B
> > > > + /* wait for B */ <- DEADLOCK
> > > > + /* start event B context */
> > > > +
> > > > + mutex_lock A
> > > > + /* wait for A */ <- DEADLOCK
> > > > + /* start event A context */
> > > > +
> > > > + folio_unlock B
> > > > + /* event B */
> > > > + folio_unlock B
> > > > + /* event B */
> > > > +
> > > > + mutex_unlock A
> > > > + /* event A */
> > > > + mutex_unlock A
> > > > + /* event A */
> > > > +
> > >
> > > I can't see the value of the above section.
> > > The first section with no comments is useful as it is easy to see the
> > > deadlock being investigate. The section below is useful as it add
> > > comments to explain how DEPT sees the situation. But the above section,
> > > with some but not all of the comments, does seem (to me) to add anything
> > > useful.
> >
> > I just wanted to convert 'locking terms' to 'wait and event terms' by
> > one step. However, I can remove the section you pointed out that you
> > thought was useless.
>
> But it seems you did it in two steps???
>
> If you think the middle section with some but not all of the comments
> adds value (And maybe it does - maybe I just haven't seen it yet), the
> please explain what value is being added at each step.
>
> It is currently documented as:
>
> +Adding comments to describe DEPT's view in terms of wait and event:
>
> then
>
> +Adding more supplementary comments to describe DEPT's view in detail:
>
> Maybe if you said more DEPT's view so at this point so that when we see
> the supplementary comments, we can understand how they relate to DEPT's
> view.
As you pointed out, I'd better remove the middle part so as to simplify
it. It doesn't give much information I also think.
> > > > +
> > > > + context X context Y context Z
> > > > +
> > > > + mutex_lock A
> > > > + /* might wait for A */
> > > > + /* start to take into account event A's context */
> > >
> > > What do you mean precisely by "context".
> >
> > That means one of task context, irq context, wq worker context (even
> > though it can also be considered as task context), or something.
>
> OK, that makes sense. If you provide this definition for "context"
> before you use the term, I think that will help the reader.
Thank you. I will add it.
> > > If the examples that follow It seems that the "context" for event A
> > > starts at "mutex lock A" when it (possibly) waits for a mutex and ends
> > > at "mutex unlock A" - which are both in the same process. Clearly
> > > various other events that happen between these two points in the same
> > > process could be seen as the "context" for event A.
> > >
> > > However event B starts in "context X" with "folio_lock B" and ends in
> > > "context Z" or "context Y" with "folio_unlock B". Is that right?
> >
> > Right.
> >
> > > My question then is: how do you decide which, of all the event in all
> > > the processes in all the system, between the start[S] and the end[E] are
> > > considered to be part of the "context" of event A.
> >
> > DEPT can identify the "context" of event A only *once* the event A is
> > actually executed, and builds dependencies between the event and the
> > recorded waits in the "context" of event A since [S].
>
> So a dependency is an ordered set of pairs of "context" and "wait" or
I don't get what you were trying to tell here. FWIW, DEPT focuses on
*event* contexts and, within each event context, it tracks pairs of
waits that appears since [S] and the interesting event that identifies
the event context.
> "context" and "event". "wait"s and "event"s are linked by some abstract
> identifier for the event (like lockdep's lock classes).
Yeah, kind of.
> How are the contexts abstracted. Is it just "same" or "different"
I don't get this. Can you explain in more detail?
Byungchul
> I'll try reading the document again and see how much further I get.
>
> Thanks,
> NeilBrown
^ permalink raw reply
* Re: [PATCH v17 28/47] dept: add documentation for dept
From: NeilBrown @ 2025-10-14 6:03 UTC (permalink / raw)
To: Byungchul Park
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, jlayton, dan.j.williams, hch, djwong,
dri-devel, rodrigosiqueiramelo, melissa.srw, hamohammed.sa,
harry.yoo, chris.p.wilson, gwan-gyeong.mun, max.byungchul.park,
boqun.feng, longman, yunseong.kim, ysk, yeoreum.yun, netdev,
matthew.brost, her0gyugyu, corbet, catalin.marinas, bp,
dave.hansen, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, okorniev, Dai.Ngo, tom, trondmy, anna, kees, bigeasy,
clrkwllms, mark.rutland, ada.coupriediaz, kristina.martsenko,
wangkefeng.wang, broonie, kevin.brodsky, dwmw, shakeel.butt, ast,
ziy, yuzhao, baolin.wang, usamaarif642, joel.granados,
richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel
In-Reply-To: <20251013052354.GA75512@system.software.com>
On Mon, 13 Oct 2025, Byungchul Park wrote:
> On Fri, Oct 03, 2025 at 04:55:14PM +1000, NeilBrown wrote:
> > On Thu, 02 Oct 2025, Byungchul Park wrote:
> > > This document describes the concept and APIs of dept.
> > >
> >
> > Thanks for the documentation. I've been trying to understand it.
>
> You're welcome. Feel free to ask me if you have any questions.
>
> > > +How DEPT works
> > > +--------------
> > > +
> > > +Let's take a look how DEPT works with the 1st example in the section
> > > +'Limitation of lockdep'.
> > > +
> > > + context X context Y context Z
> > > +
> > > + mutex_lock A
> > > + folio_lock B
> > > + folio_lock B <- DEADLOCK
> > > + mutex_lock A <- DEADLOCK
> > > + folio_unlock B
> > > + folio_unlock B
> > > + mutex_unlock A
> > > + mutex_unlock A
> > > +
> > > +Adding comments to describe DEPT's view in terms of wait and event:
> > > +
> > > + context X context Y context Z
> > > +
> > > + mutex_lock A
> > > + /* wait for A */
> > > + folio_lock B
> > > + /* wait for A */
> > > + /* start event A context */
> > > +
> > > + folio_lock B
> > > + /* wait for B */ <- DEADLOCK
> > > + /* start event B context */
> > > +
> > > + mutex_lock A
> > > + /* wait for A */ <- DEADLOCK
> > > + /* start event A context */
> > > +
> > > + folio_unlock B
> > > + /* event B */
> > > + folio_unlock B
> > > + /* event B */
> > > +
> > > + mutex_unlock A
> > > + /* event A */
> > > + mutex_unlock A
> > > + /* event A */
> > > +
> >
> > I can't see the value of the above section.
> > The first section with no comments is useful as it is easy to see the
> > deadlock being investigate. The section below is useful as it add
> > comments to explain how DEPT sees the situation. But the above section,
> > with some but not all of the comments, does seem (to me) to add anything
> > useful.
>
> I just wanted to convert 'locking terms' to 'wait and event terms' by
> one step. However, I can remove the section you pointed out that you
> thought was useless.
But it seems you did it in two steps???
If you think the middle section with some but not all of the comments
adds value (And maybe it does - maybe I just haven't seen it yet), the
please explain what value is being added at each step.
It is currently documented as:
+Adding comments to describe DEPT's view in terms of wait and event:
then
+Adding more supplementary comments to describe DEPT's view in detail:
Maybe if you said more DEPT's view so at this point so that when we see
the supplementary comments, we can understand how they relate to DEPT's
view.
>
> > > +
> > > + context X context Y context Z
> > > +
> > > + mutex_lock A
> > > + /* might wait for A */
> > > + /* start to take into account event A's context */
> >
> > What do you mean precisely by "context".
>
> That means one of task context, irq context, wq worker context (even
> though it can also be considered as task context), or something.
OK, that makes sense. If you provide this definition for "context"
before you use the term, I think that will help the reader.
> > If the examples that follow It seems that the "context" for event A
> > starts at "mutex lock A" when it (possibly) waits for a mutex and ends
> > at "mutex unlock A" - which are both in the same process. Clearly
> > various other events that happen between these two points in the same
> > process could be seen as the "context" for event A.
> >
> > However event B starts in "context X" with "folio_lock B" and ends in
> > "context Z" or "context Y" with "folio_unlock B". Is that right?
>
> Right.
>
> > My question then is: how do you decide which, of all the event in all
> > the processes in all the system, between the start[S] and the end[E] are
> > considered to be part of the "context" of event A.
>
> DEPT can identify the "context" of event A only *once* the event A is
> actually executed, and builds dependencies between the event and the
> recorded waits in the "context" of event A since [S].
So a dependency is an ordered set of pairs of "context" and "wait" or
"context" and "event". "wait"s and "event"s are linked by some abstract
identifier for the event (like lockdep's lock classes).
How are the contexts abstracted. Is it just "same" or "different"
I'll try reading the document again and see how much further I get.
Thanks,
NeilBrown
^ permalink raw reply
* Re: [PATCH v2 00/10] scalable symbol flags with __kflagstab
From: Jonathan Corbet @ 2025-10-13 19:02 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
Siddharth Nayyar <sidnayyar@google.com> writes:
> This patch series implements a mechanism for scalable exported symbol
> flags using a separate section called __kflagstab. The series introduces
> __kflagstab support, removes *_gpl sections in favor of a GPL flag,
> simplifies symbol resolution during module loading, and adds symbol
> import protection.
This caught my eye in passing ... some questions ...
The import protection would appear to be the real point of this work?
But it seems that you have kind of buried it; why not describe what you
are trying to do here and how it will be used?
I ask "how it will be used" since you don't provide any way to actually
mark exports with this new flag. What is the intended usage here?
If I understand things correctly, applying this series will immediately
result in the inability to load any previously built modules, right?
That will create a sort of flag day for anybody with out-of-tree modules
that some may well see as a regression. Is that really the intent?
Thanks,
jon
^ permalink raw reply
* [PATCH 1/2] module: Override -EEXISTS module return
From: Lucas De Marchi @ 2025-10-13 16:26 UTC (permalink / raw)
To: linux-modules, linux-kernel; +Cc: Lucas De Marchi, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com>
The -EEXIST errno is reserved by the module loading functionality. When
userspace calls [f]init_module(), it expects a -EEXIST to mean that the
module is already loaded in the kernel. If module_init() returns it,
that is not true anymore.
Add a warning and override the return code to workaround modules
currently returning the wrong code. It's expected that they eventually
migrate to a better suited error.
Closes: https://lore.kernel.org/all/aKLzsAX14ybEjHfJ@orbyte.nwl.cc/
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
kernel/module/main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b261849362..74ff87b13c517 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
if (mod->init != NULL)
ret = do_one_initcall(mod->init);
if (ret < 0) {
+ if (ret == -EEXIST) {
+ pr_warn("%s: init suspiciously returned -EEXIST: Overriding with -EBUSY\n",
+ mod->name);
+ ret = -EBUSY;
+ }
goto fail_free_freeinit;
}
if (ret > 0) {
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] module: Simplify warning on positive returns from module_init()
From: Lucas De Marchi @ 2025-10-13 16:26 UTC (permalink / raw)
To: linux-modules, linux-kernel; +Cc: Lucas De Marchi, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-0-ab65b41af01f@intel.com>
It should now be rare to trigger this warning - it doesn't need to be so
verbose. Make it follow the usual style in the module loading code.
For the same reason, drop the dump_stack().
Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
kernel/module/main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 74ff87b13c517..31c54bf6df4b2 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3045,13 +3045,9 @@ static noinline int do_init_module(struct module *mod)
}
goto fail_free_freeinit;
}
- if (ret > 0) {
- pr_warn("%s: '%s'->init suspiciously returned %d, it should "
- "follow 0/-E convention\n"
- "%s: loading module anyway...\n",
- __func__, mod->name, ret, __func__);
- dump_stack();
- }
+ if (ret > 0)
+ pr_warn("%s: init suspiciously returned %d, it should follow 0/-E convention\n",
+ mod->name, ret);
/* Now it's a first class citizen! */
mod->state = MODULE_STATE_LIVE;
--
2.51.0
^ permalink raw reply related
* [PATCH 0/2] module: Tweak return and warning
From: Lucas De Marchi @ 2025-10-13 16:26 UTC (permalink / raw)
To: linux-modules, linux-kernel; +Cc: Lucas De Marchi, Petr Pavlu
Do not let userspace tools and end users confused on the return code and
log messages.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
Lucas De Marchi (2):
module: Override -EEXISTS module return
module: Simplify warning on positive returns from module_init()
kernel/module/main.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
base-commit: e5f0a698b34ed76002dc5cff3804a61c80233a7a
change-id: 20251013-module-warn-ret-59f085298055
Lucas De Marchi
^ permalink raw reply
* [PATCH v2 10/10] module loader: enforce symbol import protection
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
The module loader will reject unsigned modules from loading if such a
module attempts to import a symbol which has the import protection bit
set in the kflagstab entry for the symbol.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/module/internal.h | 1 +
kernel/module/main.c | 10 +++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 061161cc79d9..98faaf8900aa 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -108,6 +108,7 @@ struct find_symbol_arg {
const u32 *crc;
const struct kernel_symbol *sym;
enum mod_license license;
+ bool is_protected;
};
/* modules using other modules */
diff --git a/kernel/module/main.c b/kernel/module/main.c
index f5f9872dc070..c27df62a68f5 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -380,6 +380,7 @@ static bool find_exported_symbol_in_section(const struct symsearch *syms,
fsa->crc = symversion(syms->crcs, sym - syms->start);
fsa->sym = sym;
fsa->license = (sym_flags & KSYM_FLAG_GPL_ONLY) ? GPL_ONLY : NOT_GPL_ONLY;
+ fsa->is_protected = sym_flags & KSYM_FLAG_PROTECTED;
return true;
}
@@ -1267,6 +1268,13 @@ static const struct kernel_symbol *resolve_symbol(struct module *mod,
goto getname;
}
+ if (fsa.is_protected && !mod->sig_ok) {
+ pr_warn("%s: Cannot use protected symbol %s\n",
+ mod->name, name);
+ fsa.sym = ERR_PTR(-EACCES);
+ goto getname;
+ }
+
err = ref_module(mod, fsa.owner);
if (err) {
fsa.sym = ERR_PTR(err);
@@ -1550,7 +1558,7 @@ static int simplify_symbols(struct module *mod, const struct load_info *info)
break;
ret = PTR_ERR(ksym) ?: -ENOENT;
- pr_warn("%s: Unknown symbol %s (err %d)\n",
+ pr_warn("%s: Unresolved symbol %s (err %d)\n",
mod->name, name, ret);
break;
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* [PATCH v2 09/10] modpost: add symbol import protection flag to kflagstab
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
When the unused exports whitelist is provided, the symbol protection bit
is set for symbols not present in the unused exports whitelist.
The flag will be used in the following commit to prevent unsigned
modules from the using symbols other than those explicitly declared by
the such modules ahead of time.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module_symbol.h | 1 +
scripts/mod/modpost.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/linux/module_symbol.h b/include/linux/module_symbol.h
index 574609aced99..1d0414da4c7c 100644
--- a/include/linux/module_symbol.h
+++ b/include/linux/module_symbol.h
@@ -5,6 +5,7 @@
/* Kernel symbol flags bitset. */
enum ksym_flags {
KSYM_FLAG_GPL_ONLY = 1 << 0,
+ KSYM_FLAG_PROTECTED = 1 << 1,
};
/* This ignores the intensely annoying "mapping symbols" found in ELF files. */
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 8936db84779b..8d360bab50d6 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -61,6 +61,9 @@ static bool extra_warn;
bool target_is_big_endian;
bool host_is_big_endian;
+/* Are symbols protected against being used by unsigned modules? */
+static bool default_symbol_protected_status;
+
/*
* Cut off the warnings when there are too many. This typically occurs when
* vmlinux is missing. ('make modules' without building vmlinux.)
@@ -225,6 +228,7 @@ struct symbol {
bool is_func;
bool is_gpl_only; /* exported by EXPORT_SYMBOL_GPL */
bool used; /* there exists a user of this symbol */
+ bool protected; /* this symbol cannot be used by unsigned modules */
char name[];
};
@@ -246,7 +250,8 @@ static struct symbol *alloc_symbol(const char *name)
static uint8_t get_symbol_flags(const struct symbol *sym)
{
- return sym->is_gpl_only ? KSYM_FLAG_GPL_ONLY : 0;
+ return (sym->is_gpl_only ? KSYM_FLAG_GPL_ONLY : 0) |
+ (sym->protected ? KSYM_FLAG_PROTECTED : 0);
}
/* For the hash of exported symbols */
@@ -370,6 +375,7 @@ static struct symbol *sym_add_exported(const char *name, struct module *mod,
s->namespace = xstrdup(namespace);
list_add_tail(&s->list, &mod->exported_symbols);
hash_add_symbol(s);
+ s->protected = default_symbol_protected_status;
return s;
}
@@ -1785,8 +1791,10 @@ static void handle_white_list_exports(const char *white_list)
while ((name = strsep(&p, "\n"))) {
struct symbol *sym = find_symbol(name);
- if (sym)
+ if (sym) {
sym->used = true;
+ sym->protected = false;
+ }
}
free(buf);
@@ -2294,6 +2302,7 @@ int main(int argc, char **argv)
break;
case 'u':
unused_exports_white_list = optarg;
+ default_symbol_protected_status = true;
break;
case 'W':
extra_warn = true;
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* [PATCH v2 08/10] remove references to *_gpl sections in documentation
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
Documentation/kbuild/modules.rst | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst
index d0703605bfa4..b3a26a36ee17 100644
--- a/Documentation/kbuild/modules.rst
+++ b/Documentation/kbuild/modules.rst
@@ -426,11 +426,12 @@ Symbols From the Kernel (vmlinux + modules)
Version Information Formats
---------------------------
- Exported symbols have information stored in __ksymtab or __ksymtab_gpl
- sections. Symbol names and namespaces are stored in __ksymtab_strings,
- using a format similar to the string table used for ELF. If
- CONFIG_MODVERSIONS is enabled, the CRCs corresponding to exported
- symbols will be added to the __kcrctab or __kcrctab_gpl.
+ Exported symbols have information stored in the __ksymtab and
+ __kflagstab sections. Symbol names and namespaces are stored in
+ __ksymtab_strings section, using a format similar to the string
+ table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs
+ corresponding to exported symbols will be added to the
+ __kcrctab section.
If CONFIG_BASIC_MODVERSIONS is enabled (default with
CONFIG_MODVERSIONS), imported symbols will have their symbol name and
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* [PATCH v2 07/10] linker: remove *_gpl sections from vmlinux and modules
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
These sections are not used anymore and can be removed from vmlinux and
modules.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/asm-generic/vmlinux.lds.h | 18 ++----------------
scripts/module.lds.S | 2 --
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 310e2de56211..6490b93d23b1 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -490,34 +490,20 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
\
PRINTK_INDEX \
\
- /* Kernel symbol table: Normal symbols */ \
+ /* Kernel symbol table */ \
__ksymtab : AT(ADDR(__ksymtab) - LOAD_OFFSET) { \
__start___ksymtab = .; \
KEEP(*(SORT(___ksymtab+*))) \
__stop___ksymtab = .; \
} \
\
- /* Kernel symbol table: GPL-only symbols */ \
- __ksymtab_gpl : AT(ADDR(__ksymtab_gpl) - LOAD_OFFSET) { \
- __start___ksymtab_gpl = .; \
- KEEP(*(SORT(___ksymtab_gpl+*))) \
- __stop___ksymtab_gpl = .; \
- } \
- \
- /* Kernel symbol table: Normal symbols */ \
+ /* Kernel symbol CRC table */ \
__kcrctab : AT(ADDR(__kcrctab) - LOAD_OFFSET) { \
__start___kcrctab = .; \
KEEP(*(SORT(___kcrctab+*))) \
__stop___kcrctab = .; \
} \
\
- /* Kernel symbol table: GPL-only symbols */ \
- __kcrctab_gpl : AT(ADDR(__kcrctab_gpl) - LOAD_OFFSET) { \
- __start___kcrctab_gpl = .; \
- KEEP(*(SORT(___kcrctab_gpl+*))) \
- __stop___kcrctab_gpl = .; \
- } \
- \
/* Kernel symbol flags table */ \
__kflagstab : AT(ADDR(__kflagstab) - LOAD_OFFSET) { \
__start___kflagstab = .; \
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 9a8a3b6d1569..1841a43d8771 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -20,9 +20,7 @@ SECTIONS {
}
__ksymtab 0 : ALIGN(8) { *(SORT(___ksymtab+*)) }
- __ksymtab_gpl 0 : ALIGN(8) { *(SORT(___ksymtab_gpl+*)) }
__kcrctab 0 : ALIGN(4) { *(SORT(___kcrctab+*)) }
- __kcrctab_gpl 0 : ALIGN(4) { *(SORT(___kcrctab_gpl+*)) }
__kflagstab 0 : ALIGN(1) { *(SORT(___kflagstab+*)) }
.ctors 0 : ALIGN(8) { *(SORT(.ctors.*)) *(.ctors) }
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* [PATCH v2 06/10] module loader: remove references of *_gpl sections
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
The *_gpl section are not being used populated by modpost anymore. Hence
the module loader doesn't need to find and process these sections in
modules.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/module.h | 3 ---
kernel/module/internal.h | 3 ---
kernel/module/main.c | 47 ++++++++++++++++------------------------
3 files changed, 19 insertions(+), 34 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 9ba6ce433ac3..1a9c41318e22 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -431,9 +431,6 @@ struct module {
unsigned int num_kp;
/* GPL-only exported symbols. */
- unsigned int num_gpl_syms;
- const struct kernel_symbol *gpl_syms;
- const u32 *gpl_crcs;
bool using_gplonly_symbols;
#ifdef CONFIG_MODULE_SIG
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 69b84510e097..061161cc79d9 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -53,10 +53,7 @@ extern const size_t modinfo_attrs_count;
/* Provided by the linker */
extern const struct kernel_symbol __start___ksymtab[];
extern const struct kernel_symbol __stop___ksymtab[];
-extern const struct kernel_symbol __start___ksymtab_gpl[];
-extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const u32 __start___kcrctab[];
-extern const u32 __start___kcrctab_gpl[];
extern const u8 __start___kflagstab[];
#define KMOD_PATH_LEN 256
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 4197af526087..f5f9872dc070 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1464,29 +1464,18 @@ EXPORT_SYMBOL_GPL(__symbol_get);
*/
static int verify_exported_symbols(struct module *mod)
{
- unsigned int i;
const struct kernel_symbol *s;
- struct {
- const struct kernel_symbol *sym;
- unsigned int num;
- } arr[] = {
- { mod->syms, mod->num_syms },
- { mod->gpl_syms, mod->num_gpl_syms },
- };
-
- for (i = 0; i < ARRAY_SIZE(arr); i++) {
- for (s = arr[i].sym; s < arr[i].sym + arr[i].num; s++) {
- struct find_symbol_arg fsa = {
- .name = kernel_symbol_name(s),
- .gplok = true,
- };
- if (find_symbol(&fsa)) {
- pr_err("%s: exports duplicate symbol %s"
- " (owned by %s)\n",
- mod->name, kernel_symbol_name(s),
- module_name(fsa.owner));
- return -ENOEXEC;
- }
+ for (s = mod->syms; s < mod->syms + mod->num_syms; s++) {
+ struct find_symbol_arg fsa = {
+ .name = kernel_symbol_name(s),
+ .gplok = true,
+ };
+ if (find_symbol(&fsa)) {
+ pr_err("%s: exports duplicate symbol %s"
+ " (owned by %s)\n",
+ mod->name, kernel_symbol_name(s),
+ module_name(fsa.owner));
+ return -ENOEXEC;
}
}
return 0;
@@ -2601,12 +2590,15 @@ static int find_module_sections(struct module *mod, struct load_info *info)
mod->syms = section_objs(info, "__ksymtab",
sizeof(*mod->syms), &mod->num_syms);
mod->crcs = section_addr(info, "__kcrctab");
- mod->gpl_syms = section_objs(info, "__ksymtab_gpl",
- sizeof(*mod->gpl_syms),
- &mod->num_gpl_syms);
- mod->gpl_crcs = section_addr(info, "__kcrctab_gpl");
mod->flagstab = section_addr(info, "__kflagstab");
+ if (section_addr(info, "__ksymtab_gpl"))
+ pr_warn("%s: ignoring obsolete section __ksymtab_gpl\n",
+ mod->name);
+ if (section_addr(info, "__kcrctab_gpl"))
+ pr_warn("%s: ignoring obsolete section __kcrctab_gpl\n",
+ mod->name);
+
#ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
sizeof(*mod->ctors), &mod->num_ctors);
@@ -2816,8 +2808,7 @@ static int check_export_symbol_sections(struct module *mod)
return -ENOEXEC;
}
#ifdef CONFIG_MODVERSIONS
- if ((mod->num_syms && !mod->crcs) ||
- (mod->num_gpl_syms && !mod->gpl_crcs)) {
+ if (mod->num_syms && !mod->crcs) {
return try_to_force_load(mod,
"no versions for exported symbols");
}
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* [PATCH v2 05/10] modpost: put all exported symbols in ksymtab section
From: Siddharth Nayyar @ 2025-10-13 15:39 UTC (permalink / raw)
To: petr.pavlu
Cc: arnd, linux-arch, linux-kbuild, linux-kernel, linux-modules,
mcgrof, nathan, nicolas.schier, samitolvanen, sidnayyar, maennich,
gprocida
In-Reply-To: <20251013153918.2206045-1-sidnayyar@google.com>
Since the modules loader determines whether an exported symbol is GPL
only from the kflagstab section data, modpost can put all symbols in the
regular ksymtab and stop using the *_gpl versions of the ksymtab and
kcrctab.
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
---
include/linux/export-internal.h | 21 +++++++++++----------
scripts/mod/modpost.c | 8 ++++----
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index 4123c7592404..726054614752 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -37,14 +37,14 @@
* section flag requires it. Use '%progbits' instead of '@progbits' since the
* former apparently works on all arches according to the binutils source.
*/
-#define __KSYMTAB(name, sym, sec, ns) \
+#define __KSYMTAB(name, sym, ns) \
asm(" .section \"__ksymtab_strings\",\"aMS\",%progbits,1" "\n" \
"__kstrtab_" #name ":" "\n" \
" .asciz \"" #name "\"" "\n" \
"__kstrtabns_" #name ":" "\n" \
" .asciz \"" ns "\"" "\n" \
" .previous" "\n" \
- " .section \"___ksymtab" sec "+" #name "\", \"a\"" "\n" \
+ " .section \"___ksymtab+" #name "\", \"a\"" "\n" \
__KSYM_ALIGN "\n" \
"__ksymtab_" #name ":" "\n" \
__KSYM_REF(sym) "\n" \
@@ -59,15 +59,16 @@
#define KSYM_FUNC(name) name
#endif
-#define KSYMTAB_FUNC(name, sec, ns) __KSYMTAB(name, KSYM_FUNC(name), sec, ns)
-#define KSYMTAB_DATA(name, sec, ns) __KSYMTAB(name, name, sec, ns)
+#define KSYMTAB_FUNC(name, ns) __KSYMTAB(name, KSYM_FUNC(name), ns)
+#define KSYMTAB_DATA(name, ns) __KSYMTAB(name, name, ns)
-#define SYMBOL_CRC(sym, crc, sec) \
- asm(".section \"___kcrctab" sec "+" #sym "\",\"a\"" "\n" \
- ".balign 4" "\n" \
- "__crc_" #sym ":" "\n" \
- ".long " #crc "\n" \
- ".previous" "\n")
+#define SYMBOL_CRC(sym, crc) \
+ asm(" .section \"___kcrctab+" #sym "\",\"a\"" "\n" \
+ " .balign 4" "\n" \
+ "__crc_" #sym ":" "\n" \
+ " .long " #crc "\n" \
+ " .previous" "\n" \
+ )
#define SYMBOL_FLAGS(sym, flags) \
asm(" .section \"___kflagstab+" #sym "\",\"a\"" "\n" \
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index f5ce7aeed52d..8936db84779b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1867,9 +1867,9 @@ static void add_exported_symbols(struct buffer *buf, struct module *mod)
if (trim_unused_exports && !sym->used)
continue;
- buf_printf(buf, "KSYMTAB_%s(%s, \"%s\", \"%s\");\n",
+ buf_printf(buf, "KSYMTAB_%s(%s, \"%s\");\n",
sym->is_func ? "FUNC" : "DATA", sym->name,
- sym->is_gpl_only ? "_gpl" : "", sym->namespace);
+ sym->namespace);
buf_printf(buf, "SYMBOL_FLAGS(%s, 0x%02x);\n",
sym->name, get_symbol_flags(sym));
@@ -1890,8 +1890,8 @@ static void add_exported_symbols(struct buffer *buf, struct module *mod)
sym->name, mod->name, mod->is_vmlinux ? "" : ".ko",
sym->name);
- buf_printf(buf, "SYMBOL_CRC(%s, 0x%08x, \"%s\");\n",
- sym->name, sym->crc, sym->is_gpl_only ? "_gpl" : "");
+ buf_printf(buf, "SYMBOL_CRC(%s, 0x%08x);\n",
+ sym->name, sym->crc);
}
}
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
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