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

Hi,

On 4/22/26 18:54, Scott Murray via lists.yoctoproject.org 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]

That's a good question : yes in theory but the difference is the attack 
magnitude: replacing a plain-text hash in RAM location is trivial 
compared to locating and patching kernel data structures in memory at 
runtime. On top of that standard kernel hardening via 
CONFIG_STRICT_KERNEL_RWX, IOMMU/SMMU makes those structures 
significantly harder to tamper with.

>>>> +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.
> 
> [snip]
>>> Since we're only bbappending linux-yocto in meta-security, if you'd like
>>> this to gain traction, I'd suggest extending the "Kernel Configuration"
>>> section in dm-verity.txt to outline the steps needed to add it to a
>>> vendor kernel via bbappend (i.e. adding the config fragment and required
>>> inherits).
>>
>> Good idea, I'll add a section outlining the steps needed to integrate this
>> with a vendor kernel via bbappend, covering the config fragment and required
>> inherits.
>>
>> If you agree with the above I can send a v2 addressing all those points.
> 
> That sounds good to me, please send a v2 when you have it.

I'll prepare and test the v2 then send it over.


Thanks


Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Mobile   : +4917662901545
Email    : [email protected]
Homepage : https://embetrix.com
VAT No.  : DE313902634