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

Hi Ahmad,

thanks for the review.

On 4/24/26 09:19, Ahmad Fatoum wrote:
> Hello Ayoub,
> 
> Thanks for your patch.
> 
> On 4/22/26 19:34, Ayoub Zaki wrote:
>> 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:
>>>> 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:
>>>>>> +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.
> 
> I agree.
> 
>>>> 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?
> 
> One wouldn't even need to go for the kernel keyring. The attacker can just
> directly exchange code in the kernel image itself. It lies there in RAM
> the same way as the initramfs and in the same time window.
> 
> Critically, a vast number of systems doesn't employ physical ASLR, so
> an attacker knows beforehand exactly what memory address the relevant
> parts of the kernel will be at.
> 
> 
>>>
>>> [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.
> 
> An attacker that has read/write access to DRAM can trivially search the
> page cache for an executable page of any UID 0 binary at runtime and modify
> it all the same, no? I fail to see how one is harder than the other.
> 
>> On top of that standard kernel hardening via CONFIG_STRICT_KERNEL_RWX
> 
> For the described scenario here, the attacker can directly manipulate
> physical memory, so their memory accesses wouldn't even go through the MMU
> and thus CONFIG_STRICT_KERNEL_RWX is without consequence.
> 
>> IOMMU/SMMU makes those structures significantly harder to tamper with.
> 
> Either:
> 
> - IOMMU/SMMU prevents access to kernel, so it should equally prevent access to initramfs
> - IOMMU/SMMU does not prevent access to kernel, so it would not prevent access to initramfs
> 
> The situation of having initramfs and kernel in the same memory region during
> bootloader/kernel startup, but assuming only initramfs can be modified by not the
> kernel image itself sounds a bit contrived.
> 
> Frankly, I don't see how for signed FIT configurations this offers a security
> benefit.
> 


You're right about the RAM symmetry STRICT_KERNEL_RWX IOMMU don't really 
help once you've granted the attacker DMA or JTAG.

There's a also other cases where the patch could help and it doesn't 
need RAM tampering. where root hash comes from the kernel cmdline via a 
unsigned Bootloader enviroments. An attacker could tamper the env 
offline  with their own root hash and craft a matching rootfs.
Even the secure boot chain is not interupted, dm-verity happily sets up 
against the attacker's hash and mounts their rootfs.

With CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG the kernel refuses an unsigned 
hash regardless of where it came from (enforcment via  dm_verity 
require_signatures=1 should be set)
So defense in depth not a replacement for hardware mitigations.
I can reframe the threat model in a v3 an maybe drops the RAM arguments.


> 
> I agree though that if your initramfs is outside the secure boot chain and
> it can't be easily aadded into it, this can be a workable solution.
> 
> Just keep in mind that without rotating the keys every time, this will allow
> mix-n-match attacks, e.g. an attacker could dig out a vulnerable initramfs
> and inject it into a boot flow where all other components are of the newest
> version. If that's something you want to prevent, you could equally well
> compile the initramfs into the kernel and not need any signing at all...
> 


> Cheers,
> Ahmad
> 

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