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@xxxxxxxxxxxxxx/)?

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