On 10/17/25 4:43 PM, David Howells wrote:
> Allow ML-DSA module signing to be enabled.
>
> Note that openssl's CMS_*() function suite does not, as of openssl-3.5.1,
> support the use of CMS_NOATTR with ML-DSA, so the prohibition against using
> authenticatedAttributes with module signing has to be removed. The selected
> digest then applies only to the algorithm used to calculate the digest
> stored in the messageDigest attribute.
>
> The ML-DSA algorithm uses its own internal choice of digest (SHAKE256)
> without regard to what's specified in the CMS message. This is, in theory,
> configurable, but there's currently no hook in the crypto_sig API to do
> that, though possibly it could be done by parameterising the name of the
> algorithm, e.g. ("ml-dsa87(sha512)").
>
> Signed-off-by: David Howells <[email protected]>
> cc: Lukas Wunner <[email protected]>
> cc: Ignat Korchagin <[email protected]>
> cc: Stephan Mueller <[email protected]>
> cc: Eric Biggers <[email protected]>
> cc: Herbert Xu <[email protected]>
> cc: [email protected]
> cc: [email protected]
> ---
> Documentation/admin-guide/module-signing.rst | 15 +++++------
> certs/Kconfig | 24 ++++++++++++++++++
> certs/Makefile | 3 +++
> crypto/asymmetric_keys/pkcs7_verify.c | 4 ---
> kernel/module/Kconfig | 5 ++++
> scripts/sign-file.c | 26 ++++++++++++++------
> 6 files changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/admin-guide/module-signing.rst
> b/Documentation/admin-guide/module-signing.rst
> index a8667a777490..6daff80c277b 100644
> --- a/Documentation/admin-guide/module-signing.rst
> +++ b/Documentation/admin-guide/module-signing.rst
> @@ -28,10 +28,11 @@ trusted userspace bits.
>
> This facility uses X.509 ITU-T standard certificates to encode the public
> keys
> involved. The signatures are not themselves encoded in any industrial
> standard
> -type. The built-in facility currently only supports the RSA & NIST P-384
> ECDSA
> -public key signing standard (though it is pluggable and permits others to be
> -used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
> -sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
> +type. The built-in facility currently only supports the RSA, NIST P-384
> ECDSA
> +and NIST FIPS-204 ML-DSA (Dilithium) public key signing standards (though it
> is
> +pluggable and permits others to be used). For RSA and ECDSA, the possible
> hash
> +algorithms that can be used are SHA-2 and SHA-3 of sizes 256, 384, and 512
> (the
> +algorithm is selected by data in the signature); ML-DSA uses SHAKE256.
This update looks ok to me. However, I'll note some problems that
I noticed in the original text, notably:
The text doesn't match the implementation because kernel/module/Kconfig
still allows selecting SHA-1 for module signing. What happened is that
commit 16ab7cb5825f ("crypto: pkcs7 - remove sha1 support") initially
removed CONFIG_MODULE_SIG_SHA1. Then, commit f2b88bab69c8
("Documentation/module-signing.txt: bring up to date") removed it from
the documentation. However, commit 203a6763ab69 ("Revert "crypto: pkcs7
- remove sha1 support"") brought back CONFIG_MODULE_SIG_SHA1 without
reverting the documentation update.
Another problem is that for MODULE_SIG_KEY_TYPE_ECDSA, certs/Kconfig
contains the line
"depends on !(MODULE_SIG_SHA256 || MODULE_SIG_SHA3_256)",
which intends to allow ECDSA only with MODULE_SIG_SHA384,
MODULE_SIG_SHA512, MODULE_SIG_SHA3_384 and MODULE_SIG_SHA3_512. This
restriction was added in commit d4f5bfe20da9 ("certs: Limit
MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512") and 446b1e0b7b39
("module: enable automatic module signing with FIPS 202 SHA-3").
However, the documentation suggests that ECDSA can still be used with
SHA-2/3 of size 256.
I'll prepare fixes for these issues. For the first problem, I think we
can drop CONFIG_MODULE_SIG_SHA1 instead of correcting the documentation.
>
>
> ==========================
> @@ -146,9 +147,9 @@ into vmlinux) using parameters in the::
>
> file (which is also generated if it does not already exist).
>
> -One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
> -(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
> -P-384 keypair.
> +One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``), ECDSA
> +(``MODULE_SIG_KEY_TYPE_ECDSA``) and ML-DSA (``MODULE_SIG_KEY_TYPE_ML_DSA``)
> to
> +generate an RSA 4k, a NIST P-384 keypair or an ML-DSA keypair.
>
> It is strongly recommended that you provide your own x509.genkey file.
>
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 78307dc25559..a09db4b2c87c 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -39,6 +39,30 @@ config MODULE_SIG_KEY_TYPE_ECDSA
> Note: Remove all ECDSA signing keys, e.g. certs/signing_key.pem,
> when falling back to building Linux 5.14 and older kernels.
>
> +config MODULE_SIG_KEY_TYPE_ML_DSA_44
> + bool "ML-DSA (Dilithium) 44"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
Copy-and-paste error in the help message: 87 -> 44.
> +
> +config MODULE_SIG_KEY_TYPE_ML_DSA_65
> + bool "ML-DSA (Dilithium) 65"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
Similarly here: 87 -> 65.
> +
> +config MODULE_SIG_KEY_TYPE_ML_DSA_87
> + bool "ML-DSA (Dilithium) 87"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
> +
Should all MODULE_SIG_KEY_TYPE_ML_DSA_* options depend on
MODULE_SIG_SHAKE256 to match the updated
Documentation/admin-guide/module-signing.rst?
Similarly, do MODULE_SIG_KEY_TYPE_RSA and MODULE_SIG_KEY_TYPE_ECDSA
require any "depends on" update with respect to the addition of
MODULE_SIG_SHAKE256?
--
Thanks,
Petr
