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