Re: [yocto-patches] [meta-security][PATCH] dm-verity: add PKCS#7 root hash signature support

On Wed, 22 Apr 2026, 18:54 Scott Murray, <[email protected]> wrote:

> On Wed, 22 Apr 2026, Ayoub Zaki via lists.yoctoproject.org wrote:
>
> > Hi Scott, Marta,
> >
> > Thanks for the review and for testing effort.
> >
> > On 4/21/26 22:45, Scott Murray via lists.yoctoproject.org wrote:
> > > On Mon, 20 Apr 2026, Ayoub Zaki via lists.yoctoproject.org wrote:
> > >
> > >> The dm-verity root hash stored in the initramfs is vulnerable to
> TOCTOU
> > >> attacks. Mitigate this by signing the root hash at build time and
> > >> verifying it from the kernel via CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG.
> > >> The signature is deployed into the initramfs while the signing
> certificate
> > >> is embedded in the kernel's built-in trusted keyring.
> > >>
> > >> - dm-verity-img.bbclass: sign root hash with openssl smime when
> > >> DM_VERITY_SIGN=1
> > >> - kernel-trusted-keys.bbclass: new shared class to collect PEM certs
> > >>    into trusted_keys.pem via KERNEL_TRUSTED_CERTS variable
> > >> - linux-yocto_security.inc: add kernel config fragments and append
> > >>    signing cert via KERNEL_TRUSTED_CERTS
> > >> - dm-verity-image-initramfs.bb: deploy .p7s signature
> > >> - dmverity initrd script: pass --root-hash-signature to veritysetup
> > >> - linux_ima.inc: use KERNEL_TRUSTED_CERTS instead of absolute path in
> > >>    CONFIG_SYSTEM_TRUSTED_KEYS, fixing buildpaths QA
> > >> - Add debug/test keys and documentation
> > >>
> > >> Signing is not enabled by default for backward compatibility but is
> > >> strongly recommended for production deployments.
> > >
> > > I believe Marta is doing some testing of this, and I'll try to do some
> > > as well in the next couple of days.  I do have some comments that I'll
> put
> > > inline below.
> > >
> > >> Signed-off-by: Ayoub Zaki <[email protected]>
> > >> ---
> > >>   classes/dm-verity-img.bbclass                 | 46 +++++++++++-
> > >>   classes/kernel-trusted-keys.bbclass           | 34 +++++++++
> > >>   docs/dm-verity.txt                            | 73
> +++++++++++++++++++
> > >>   meta-integrity/data/debug-keys/README.md      |  7 ++
> > >>   .../data/debug-keys/privkey_verity.pem        | 52 +++++++++++++
> > >>   .../data/debug-keys/x509_verity.crt           | 30 ++++++++
> > >>   .../recipes-kernel/linux/linux_ima.inc        |  9 +--
> > >>   .../images/dm-verity-image-initramfs.bb       |  6 ++
> > >>   .../initramfs-framework-dm/dmverity           |  7 ++
> > >>   .../linux/files/dm-verity-verify.cfg          | 10 +++
> > >>   .../linux/files/dm-verity-verify.scc          |  5 ++
> > >>   recipes-kernel/linux/linux-yocto_security.inc | 10 +++
> > >>   12 files changed, 283 insertions(+), 6 deletions(-)
> > >>   create mode 100644 classes/kernel-trusted-keys.bbclass
> > >>   create mode 100644 meta-integrity/data/debug-keys/privkey_verity.pem
> > >>   create mode 100644 meta-integrity/data/debug-keys/x509_verity.crt
> > >>   create mode 100644 recipes-kernel/linux/files/dm-verity-verify.cfg
> > >>   create mode 100644 recipes-kernel/linux/files/dm-verity-verify.scc
> > >>
> > >> diff --git a/classes/dm-verity-img.bbclass
> b/classes/dm-verity-img.bbclass
> > >> index 48557e9..fba8454 100644
> > >> --- a/classes/dm-verity-img.bbclass
> > >> +++ b/classes/dm-verity-img.bbclass
> > >> @@ -3,6 +3,12 @@
> > >>   # Copyright (C) 2020 BayLibre SAS
> > >>   # Author: Bartosz Golaszewski <[email protected]>
> > >>   #
> > >> +# Copyright 2026 Embetrix Embedded Systems Solutions
> > >> <[email protected]>
> > >
> > > Please use "Copyright (C)" for consistency, this applies to the other
> > > files changed/added as well.
> >
> > Agreed, will fix for consistency.
> >
> [snip]
> > >> +do_shared_workdir:append() {
> > >> +    if [ -f trusted_keys.pem ]; then
> > >> +        cp trusted_keys.pem $kerneldir/
> > >> +    fi
> > >> +}
> > >
> > > Since you're storing this aggregated set of keys in work-shared, it
> > > probably needs to be explicitly documented that TMPDIR should not be
> > > accessible by other users, as that may not be obvious to some folks.
> > >
> >
> > Worth noting that the "trusted keys" naming here is inherited from the
> > kernel's own CONFIG_SYSTEM_TRUSTED_KEYS convention and is somewhat
> misleading:
> > these are certificates only. The kernel's built-in trusted keyring does
> not
> > handle private keys at all.
> > The same pattern is already used by the kernel-modsign.bbclass which
> this was
> > modeled after.
> > That said, I'm happy to add a note clarifying this in the documentation
> to
> > avoid confusion.
>
> Okay, that sounds good.
>
> > >> diff --git a/docs/dm-verity.txt b/docs/dm-verity.txt
> > >> index a538fa2..9d326bf 100644
> > >> --- a/docs/dm-verity.txt
> > >> +++ b/docs/dm-verity.txt
> > >> @@ -121,3 +121,76 @@ INFO: The image(s) were created using OE
> kickstart
> > >> file:
> > >>   The "direct" image contains the partition table, bootloader, and
> > >>   dm-verity
> > >>   enabled ext4 image all in one -- ready to write to a raw device,
> such as
> > >>   a
> > >>   u-SD card in the case of the beaglebone.
> > >> +
> > >> +Root Hash Signature Verification
> > >> +--------------------------------
> > >> +By default, dm-verity stores the root hash as plain text in the
> initramfs
> > >> +at /usr/share/misc/dm-verity.env. This creates a TOCTOU
> (time-of-check to
> > >> +time-of-use) vulnerability: an attacker who can modify the initramfs
> can
> > >> +replace both the root hash and the filesystem image, defeating
> dm-verity.
> > >
> > > Just to double check I'm clear wrt the attack scenario, this only works
> > > if the initramfs is outside the secure boot chain, i.e. stored as a
> > > separate file from the kernel?  I'm thinking that perhaps secure boot
> > > with FIT images avoids the problem, and that's not uncommon these days.
> > > And I'm guessing initramfs bundled with the kernel might also avoid
> TOCTOU
> > > w/o a more elaborate attack.  If so, it might be good to be more
> explicit
> > > here wrt the insecure scenario.
> > >
> >
> > The scenario this addresses is precisely when the initramfs is verified
> at an
> > earlier boot stage (e.g. bundled with the kernel or part of a signed FIT
> > image) but there is a multi-second window between that verification and
> the
> > actual use of the root hash where memory contents can be modified: The
> > specific techniques to exploit this window vary depending on hardware
> (DMA
> > attacks, JTAG, etc.). I'll clarify this in the documentation so readers
> > understand the attack surface more precisely.
>
> Gotcha.  I'm all for your changes as they will add another layer of
> defense, but I am curious if a determined attacker with that capability
> might also be able to flip off the signature verification flag, or
> potentially overwrite the kernel keyring?
>
> [snip]
> > >> +These are insecure debug/test keys. Generate your own for production
> use.
> > >> +
> > >
> > > I would strongly prefer that we not add any more debug keys in-tree, as
> > > there's a chance someone might go ahead and use them, and they
> sometimes
> > > generate spam from folks running scanners on public repos (I've
> > > experienced this on other projects).  If we were to add a selftest, it
> > > can generate a key on the fly.  If there's a strong reason they should
> be
> > > added that I'm missing, I'd say these ones should probably not be in
> > > meta-integrity, as dm-verity-img.bbclass is in the base layer, not
> > > meta-integrity.
> > >
> >
> > Fully agree. I'll remove the in-tree debug keys. On a related note I
> think the
> > verity related implementation should probably land in meta-integrity as
> well,
> > rather than in base layer.
>
> I can see that view, but I suspect the ship has maybe already sailed given
> the bbclass has been in meta-security for a while now.  If we were going
> to move it, we're currently in a narrow window before we create the
> wrynose branch for LTS where it might make sense.  Marta may have a
> better idea of how much impact that would be for downstreams, I'm actually
> not sure myself.
>
>
The meta-integrity layer has a separate DISTRO_FEATURE to enable and it adds
kernel options and such. This makes big change for users of this class and
am not
sure how many are using it separately from meta-integrity. So I think it is
too late to
move in this cycle.

Kind regards,
Marta