[PATCH 0/2] Add bulk signing support for PKCS#11 keys

[PATCH 0/2] Add bulk signing support for PKCS#11 keys

[Massimiliano Marretta]

Add support for signing kernel modules in bulk when the signing
key is stored on a PKCS#11 token.

Currently scripts/sign-file signs one module per invocation. When
the key lives on a PKCS#11 token (e.g. a Nitrokey HSM or a
SmartCard-HSM), every invocation pays a fixed initialization cost
of 25-36 seconds, which dominates the actual signing time. For a
typical build with hundreds of modules this is impractical.

This series adds a '-b' (bulk) option to scripts/sign-file and
teaches the kbuild system to use it automatically when the signing
key is provided as a PKCS#11 URI. The classic one-module-at-a-time
behavior is preserved when the key is a PEM file.

Patch 1/2 also extracts the body of the signing logic into a
dedicated sign_single_file() helper. This is done to keep the
new bulk loop in main() readable and to avoid duplicating the
argument parsing logic. The extracted function contains no
functional changes with respect to the current upstream code.

Measured on a build with 50 modules and the key stored on a
SmartCard-HSM:
  - before: ~24 minutes
  - after:  ~3 min 17 s

Note on checkpatch: the series produces a few "trailing statements
should be on next line" errors on sign-file.c. These come from the
switch statement in main() that is moved within the file by patch
1/2. The affected lines use the exact same style as the current
upstream sources (case 'x': stmt; break;) and are not introduced
by this series.

Massimiliano Marretta (2):
  scripts/sign-file: add bulk module signing support
  kbuild: sign modules in bulk when the signing key is on PKCS#11

 scripts/Makefile.modinst |  43 ++++++++++-
 scripts/sign-file.c      | 159 ++++++++++++++++++++++++---------------
 2 files changed, 142 insertions(+), 60 deletions(-)

-- 
2.43.0

[PATCH 1/2] scripts/sign-file: add bulk module signing support

[Massimiliano Marretta]

When signing kernel modules with a private key stored on a PKCS#11
token (e.g. a Nitrokey HSM or a SmartCard-HSM), every invocation of
scripts/sign-file pays a fixed initialization cost that dominates
the actual signing time. On the reported hardware this cost is
about 25-36 seconds per invocation, mostly spent in token
initialization, PIN verification and session setup.

Since a typical kernel build produces hundreds of modules, signing
them one by one is impractical.

Add a new '-b' (bulk) option that accepts multiple module files in
a single invocation. The private key and the X.509 certificate are
loaded once, then each module is signed in sequence, reusing the
same OpenSSL and PKCS#11 context.

Measured on 50 modules with a key stored on a SmartCard-HSM:
  - individual invocations: ~24 minutes
  - bulk mode:              ~3 min 17 s

The fixed per-invocation overhead is eliminated (~25-36 s), while
the per-module cost is unchanged (~3.2 s).

The default behavior is unchanged: without '-b', sign-file works
exactly as before.

Signed-off-by: Massimiliano Marretta <massimiliano.marretta@egicon.com>
---
 scripts/sign-file.c | 159 ++++++++++++++++++++++++++++----------------
 1 file changed, 100 insertions(+), 59 deletions(-)

diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index 86b010ac1514..241f4538fd17 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -46,9 +46,11 @@ static __attribute__((noreturn))
 void format(void)
 {
 	fprintf(stderr,
-		"Usage: scripts/sign-file [-dp] <hash algo> <key> <x509> <module> [<dest>]\n");
+		"Usage: scripts/sign-file [-dpk] <hash algo> <key> <x509> <module> [<dest>]\n");
 	fprintf(stderr,
 		"       scripts/sign-file -s <raw sig> <hash algo> <x509> <module> [<dest>]\n");
+	fprintf(stderr,
+		"       scripts/sign-file -b [-dpk] <hash algo> <key> <x509> <module> [<module> ...]\n");
 	exit(2);
 }
 
@@ -183,76 +185,25 @@ static X509 *read_x509(const char *x509_name)
 	return x509;
 }
 
-int main(int argc, char **argv)
+static void sign_single_file(const char *hash_algo, const char *module_name,
+			     const char *dest_name, bool replace_orig,
+			     bool save_sig, bool sign_only, bool raw_sig,
+			     const char *raw_sig_name, unsigned int use_keyid,
+			     EVP_PKEY *private_key, X509 *x509)
 {
 	struct module_signature sig_info = { .id_type = MODULE_SIGNATURE_TYPE_PKCS7 };
-	char *hash_algo = NULL;
-	char *private_key_name = NULL, *raw_sig_name = NULL;
-	char *x509_name, *module_name, *dest_name;
-	bool save_sig = false, replace_orig;
-	bool sign_only = false;
-	bool raw_sig = false;
 	unsigned char buf[4096];
 	unsigned long module_size, sig_size;
 	const EVP_MD *digest_algo;
-	EVP_PKEY *private_key;
 	CMS_ContentInfo *cms = NULL;
-	unsigned int use_keyid = 0;
-	X509 *x509;
 	BIO *bd, *bm;
-	int opt, n;
-	OpenSSL_add_all_algorithms();
-	ERR_load_crypto_strings();
-	ERR_clear_error();
-
-	key_pass = getenv("KBUILD_SIGN_PIN");
-
-	do {
-		opt = getopt(argc, argv, "sdpk");
-		switch (opt) {
-		case 's': raw_sig = true; break;
-		case 'p': save_sig = true; break;
-		case 'd': sign_only = true; save_sig = true; break;
-		case 'k': use_keyid = CMS_USE_KEYID; break;
-		case -1: break;
-		default: format();
-		}
-	} while (opt != -1);
-
-	argc -= optind;
-	argv += optind;
-	if (argc < 4 || argc > 5)
-		format();
-
-	if (raw_sig) {
-		raw_sig_name = argv[0];
-		hash_algo = argv[1];
-	} else {
-		hash_algo = argv[0];
-		private_key_name = argv[1];
-	}
-	x509_name = argv[2];
-	module_name = argv[3];
-	if (argc == 5 && strcmp(argv[3], argv[4]) != 0) {
-		dest_name = argv[4];
-		replace_orig = false;
-	} else {
-		ERR(asprintf(&dest_name, "%s.~signed~", module_name) < 0,
-		    "asprintf");
-		replace_orig = true;
-	}
+	int n;
 
 	/* Open the module file */
 	bm = BIO_new_file(module_name, "rb");
 	ERR(!bm, "%s", module_name);
 
 	if (!raw_sig) {
-		/* Read the private key and the X.509 cert the PKCS#7 message
-		 * will point to.
-		 */
-		private_key = read_private_key(private_key_name);
-		x509 = read_x509(x509_name);
-
 		/* Digest the module data. */
 		OpenSSL_add_all_digests();
 		drain_openssl_errors(__LINE__, 0);
@@ -307,7 +258,8 @@ int main(int argc, char **argv)
 
 		if (sign_only) {
 			BIO_free(bm);
-			return 0;
+			CMS_ContentInfo_free(cms);
+			return;
 		}
 	}
 
@@ -354,5 +306,94 @@ int main(int argc, char **argv)
 	if (replace_orig)
 		ERR(rename(dest_name, module_name) < 0, "%s", dest_name);
 
+	CMS_ContentInfo_free(cms);
+}
+
+int main(int argc, char **argv)
+{
+	char *hash_algo = NULL;
+	char *private_key_name = NULL, *raw_sig_name = NULL;
+	char *x509_name, *module_name, *dest_name;
+	bool save_sig = false, replace_orig;
+	bool sign_only = false;
+	bool raw_sig = false, bulk = false;
+	EVP_PKEY *private_key = NULL;
+	X509 *x509 = NULL;
+	unsigned int use_keyid = 0;
+	int opt, i, nmodules;
+
+	OpenSSL_add_all_algorithms();
+	ERR_load_crypto_strings();
+	ERR_clear_error();
+
+	key_pass = getenv("KBUILD_SIGN_PIN");
+
+	do {
+		opt = getopt(argc, argv, "sdpkb");
+		switch (opt) {
+		case 's': raw_sig = true; break;
+		case 'p': save_sig = true; break;
+		case 'd': sign_only = true; save_sig = true; break;
+		case 'k': use_keyid = CMS_USE_KEYID; break;
+		case 'b': bulk = true; break;
+		case -1: break;
+		default: format();
+		}
+	} while (opt != -1);
+
+	argc -= optind;
+	argv += optind;
+
+	if (raw_sig && bulk)
+		format();
+
+	if (bulk) {
+		if (argc < 4)
+			format();
+	} else if (argc < 4 || argc > 5) {
+		format();
+	}
+
+	if (raw_sig) {
+		raw_sig_name = argv[0];
+		hash_algo = argv[1];
+	} else {
+		hash_algo = argv[0];
+		private_key_name = argv[1];
+	}
+	x509_name = argv[2];
+
+	if (!raw_sig) {
+		private_key = read_private_key(private_key_name);
+		x509 = read_x509(x509_name);
+	}
+
+	/* In bulk mode all remaining arguments are module names.  In the
+	 * normal mode there is exactly one module name.
+	 */
+	nmodules = bulk ? argc - 3 : 1;
+	for (i = 0; i < nmodules; i++) {
+		module_name = argv[3 + i];
+		dest_name = NULL;
+		replace_orig = true;
+
+		if (!bulk && argc == 5 && strcmp(argv[3], argv[4]) != 0) {
+			dest_name = argv[4];
+			replace_orig = false;
+		} else {
+			ERR(asprintf(&dest_name, "%s.~signed~", module_name) < 0,
+			    "asprintf");
+		}
+
+		sign_single_file(hash_algo, module_name, dest_name, replace_orig,
+				 save_sig, sign_only, raw_sig, raw_sig_name, use_keyid,
+				 private_key, x509);
+
+		if (replace_orig)
+			free(dest_name);
+	}
+
+	EVP_PKEY_free(private_key);
+	X509_free(x509);
 	return 0;
 }
-- 
2.43.0

[PATCH 2/2] kbuild: sign modules in bulk when the signing key is on PKCS#11

[Massimiliano Marretta]

When CONFIG_MODULE_SIG_KEY contains a PKCS#11 URI, each module is
currently signed by a separate invocation of scripts/sign-file.
This is inefficient because every invocation pays the fixed cost
of initializing the PKCS#11 token, verifying the PIN and setting
up the session, which can take tens of seconds per module.

Use the newly added '-b' option of scripts/sign-file to sign all
modules in a single invocation when the signing key is provided
as a PKCS#11 URI. Modules are installed first, then signed in
bulk in a dedicated target that runs before depmod.

When the signing key is a PEM file, the classic per-module signing
path is kept unchanged, since the bulk mode provides no benefit
in that case.

Measured on a build with 50 modules and the key stored on a
SmartCard-HSM:
  - before: ~24 minutes
  - after:  ~3 min 17 s

Signed-off-by: Massimiliano Marretta <massimiliano.marretta@egicon.com>
---
 scripts/Makefile.modinst | 43 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index 9ba45e5b32b1..e7894d195e7d 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -101,34 +101,63 @@ endif
 #
 ifeq ($(filter pkcs11:%, $(CONFIG_MODULE_SIG_KEY)),)
 sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(objtree)/)$(CONFIG_MODULE_SIG_KEY)
+sign-bulk :=
 else
 sig-key := $(CONFIG_MODULE_SIG_KEY)
+# Signing via a PKCS#11 URI is much faster in bulk mode, as the
+# per-invocation initialization cost of the token is high.
+sign-bulk := 1
 endif
+
 quiet_cmd_sign = SIGN    $@
       cmd_sign = $(objtree)/scripts/sign-file $(CONFIG_MODULE_SIG_HASH) "$(sig-key)" $(objtree)/certs/signing_key.x509 $@ \
                  $(if $(KBUILD_EXTMOD),|| true)
 
+quiet_cmd_bulk_sign = BULK SIGN
+      cmd_bulk_sign = $(objtree)/scripts/sign-file -b $(CONFIG_MODULE_SIG_HASH) "$(sig-key)" $(objtree)/certs/signing_key.x509 $(modules) \
+                     $(if $(KBUILD_EXTMOD),|| true)
+
 ifeq ($(sign-only),)
 
 # During modules_install, modules are signed only when CONFIG_MODULE_SIG_ALL=y.
 ifndef CONFIG_MODULE_SIG_ALL
 quiet_cmd_sign :=
       cmd_sign := :
+quiet_cmd_bulk_sign :=
+      cmd_bulk_sign := :
 endif
 
 # Create necessary directories
 $(foreach dir, $(sort $(dir $(install-y))), $(shell mkdir -p $(dir)))
 
+ifeq ($(sign-bulk),)
+
 $(dst)/%.ko: %.ko FORCE
 	$(call cmd,install)
 	$(call cmd,strip)
 	$(call cmd,sign)
 
+else
+
+$(dst)/%.ko: %.ko FORCE
+	$(call cmd,install)
+	$(call cmd,strip)
+
+PHONY += bulk-sign-modules
+bulk-sign-modules: $(install-y)
+	$(call cmd,bulk_sign)
+
+__modinst: bulk-sign-modules
+
+BULK_SIGN_DEP := bulk-sign-modules
+
+endif
+
 ifdef CONFIG_MODULES
 __modinst: depmod
 
 PHONY += depmod
-depmod: $(install-y)
+depmod: $(install-y) $(BULK_SIGN_DEP)
 	$(call cmd,depmod)
 
 quiet_cmd_depmod = DEPMOD  $(MODLIB)
@@ -137,9 +166,21 @@ endif
 
 else
 
+ifeq ($(sign-bulk),)
+
 $(dst)/%.ko: FORCE
 	$(call cmd,sign)
 
+else
+
+PHONY += bulk-sign-modules
+bulk-sign-modules: $(install-y)
+	$(call cmd,bulk_sign)
+
+__modinst: bulk-sign-modules
+
+endif
+
 endif
 
 #
-- 
2.43.0

Re: [PATCH 0/2] Add bulk signing support for PKCS#11 keys

[Eric Biggers]

On Fri, Oct 09, 2026 at 12:19:13PM +0200, Massimiliano Marretta wrote:
> Add support for signing kernel modules in bulk when the signing
> key is stored on a PKCS#11 token.
> 
> Currently scripts/sign-file signs one module per invocation. When
> the key lives on a PKCS#11 token (e.g. a Nitrokey HSM or a
> SmartCard-HSM), every invocation pays a fixed initialization cost
> of 25-36 seconds, which dominates the actual signing time. For a
> typical build with hundreds of modules this is impractical.

Can you elaborate on what problem you're trying to solve by using not
only asymmetric signatures, but also an HSM to hold the private key?

Have you considered hash-based integrity checking
(https://lore.kernel.org/linux-modules/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net/)?

- Eric

Re: [PATCH 0/2] Add bulk signing support for PKCS#11 keys

[Massimiliano Marretta]

On Fri, Oct 09, 2026 at 03:52:28PM +0200, Eric Biggers wrote:
> On Fri, Oct 09, 2026 at 12:19:13PM +0200, Massimiliano Marretta wrote:
> > Add support for signing kernel modules in bulk when the signing
> > key is stored on a PKCS#11 token.
> > 
> > Currently scripts/sign-file signs one module per invocation. When
> > the key lives on a PKCS#11 token (e.g. a Nitrokey HSM or a
> > SmartCard-HSM), every invocation pays a fixed initialization cost
> > of 25-36 seconds, which dominates the actual signing time. For a
> > typical build with hundreds of modules this is impractical.
> 
> Can you elaborate on what problem you're trying to solve by using not
> only asymmetric signatures, but also an HSM to hold the private key?

Sure, and thanks for asking. The HSM is not a choice made by this
patch; it is a deployment requirement we have to meet.

We are implementing the cybersecurity requirements for the EU Radio
Equipment Directive (RED), specifically EN 18031, on a device based
on an NXP i.MX8MM. To satisfy those requirements, all production
keys -- including the module signing key -- must be held on an HSM
with controlled access. Keeping the private key on a file would not
meet the compliance requirements, and the same token is used for
other artifacts in the secure-boot chain.

PKCS#11 support for the signing key already exists in
scripts/sign-file and in the kbuild Makefiles; this series does not
introduce the HSM. What it addresses is the fact that, under that
constraint, signing hundreds of modules with one invocation each is
impractical. Measured on a real product build with 802 modules and
the key stored on a SmartCard-HSM:

  - individual invocations: ~6 h 28 min
  - bulk mode:              ~42 min

> 
> Have you considered hash-based integrity checking
> (https://lore.kernel.org/linux-modules/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net/)?

Yes, I have been following that series. It is a useful approach for
its stated goal, and I am not arguing against it.

However, in our case it is not applicable. Our product depends on
Wi-Fi modules from Ezurio that are built out-of-tree against the
Engicam/NXP kernel. In this case the module hash is not known at
vmlinux link time, so a Merkle tree computed during the kernel build
cannot cover them. Asymmetric signatures remain the only supported
verification path for those modules, which means the signing key has
to stay on the HSM and the per-invocation token initialization cost
remains a real problem.

So the two mechanisms address different scenarios and are not in
competition. This patch is a local optimization of the signing path
that exists today: it is a no-op when the signing key is a PEM file,
and it can be dropped if asymmetric module signatures ever go away
entirely.

Thanks,
Massimiliano


> 
> - Eric

Re: [PATCH 0/2] Add bulk signing support for PKCS#11 keys

[Eric Biggers]

On Fri, Oct 09, 2026 at 06:13:22PM +0200, Massimiliano Marretta wrote:
> Yes, I have been following that series. It is a useful approach for
> its stated goal, and I am not arguing against it.
> 
> However, in our case it is not applicable. Our product depends on
> Wi-Fi modules from Ezurio that are built out-of-tree against the
> Engicam/NXP kernel. In this case the module hash is not known at
> vmlinux link time, so a Merkle tree computed during the kernel build
> cannot cover them.

But do you actually deploy a kernel (maybe with some in-tree modules),
and then deploy the out-of-tree modules later at some totally separate
time?

Or do you actually just collect both in-tree and out-of-tree artifacts
into a build and deploy that, and the fact that the in-tree build
doesn't have visibility into out-of-tree modules built separately is
just a limitation of the build system?  If so, asymmetric signatures
seem like a really unnecessarily complicated workaround for that.

- Eric

Re: [PATCH 0/2] Add bulk signing support for PKCS#11 keys

[Massimiliano Marretta]

On Fri, Oct 09, 2026 at 06:26:08PM +0200, Eric Biggers wrote:
> On Fri, Oct 09, 2026 at 06:13:22PM +0200, Massimiliano Marretta wrote:
> > Yes, I have been following that series. It is a useful approach for
> > its stated goal, and I am not arguing against it.
> > 
> > However, in our case it is not applicable. Our product depends on
> > Wi-Fi modules from Ezurio that are built out-of-tree against the
> > Engicam/NXP kernel. In this case the module hash is not known at
> > vmlinux link time, so a Merkle tree computed during the kernel build
> > cannot cover them.
> 
> But do you actually deploy a kernel (maybe with some in-tree modules),
> and then deploy the out-of-tree modules later at some totally separate
> time?
> 
> Or do you actually just collect both in-tree and out-of-tree artifacts
> into a build and deploy that, and the fact that the in-tree build
> doesn't have visibility into out-of-tree modules built separately is
> just a limitation of the build system?  If so, asymmetric signatures
> seem like a really unnecessarily complicated workaround for that.
> 
> - Eric

Both the build and the deployment are separate, and we need to be
able to update the out-of-tree modules independently.

Concretely, the build is two stages:

  1. the base kernel is built from the Engicam/NXP BSP and its in-tree
     modules are installed into the rootfs;
  2. the Ezurio Wi-Fi backport is built afterwards, in a separate source
     tree, pointing at the kernel build directory:

        export KLIB_BUILD=/.../linux-imx-engicam
        make defconfig-lwb
        make
        make modules_install INSTALL_MOD_PATH=/.../rootfs

     and its modules are installed into the same rootfs.

So even at build time the two trees do not share a link step, and the
kernel has no visibility into the Ezurio modules when vmlinux is
linked. That alone rules out a Merkle-root mechanism computed at
vmlinux link time.

But the more important point is deployment. The Wi-Fi stack is
delivered and updated on Ezurio's cadence, independently of the base
firmware, and we must be able to ship a new set of Ezurio modules to
a device in the field without rebuilding and reflashing the kernel.
This is a product requirement, not a build-system limitation. A
hash-based scheme tied to the vmlinux build could not cover such an
update: the kernel has already been deployed, and the new module
hashes are not in it.

Asymmetric signatures are what allow the two halves to be produced
and updated independently, and still be verified by the running
kernel using the public key it already carries.

There is also a compliance requirement that is independent of the
build system. We are implementing EN 18031 under the EU RED, which
requires secure update mechanisms and integrity protection based on
digital signatures. The compliance approach we have adopted for our
hardware is a hardware-rooted chain of trust based on asymmetric
signatures for both Secure Boot and module loading. Even if the build
were fully unified, the signing path would still be asymmetric, and
the HSM constraint would still apply.

So the question you raise is fair, but the answer is not "unify the
build" -- it is "the two halves are genuinely independent, in both
build and deployment". This patch only makes the asymmetric signing
path that already exists practical under that constraint.

Thanks,
Massimiliano