Re: [Buildroot] dm-verity: Rebuilding the kernel/FIT after rootfs - Support in Buildroot

On Thu, 2026-08-20 at 09:11 +0000, Manikandan M - I67131 wrote:
> Hello,
> 
Hi Manikandan,

> We are adding verified boot (dm-verity) to an ARM board in Buildroot,
> using a dracut initramfs that opens the dm-verity device and 
> switch_roots to a read-only squashfs. We have a working proof of 
> concept, but getting there required working around Buildroot's build 
> ordering, and we would like the list's/maintainers' view on whether 
> there is a cleaner, supported way to express this.
> 
> In Yocto(based on my understanding), the flow falls out with
> dependency 
> graph (bitbake DAG):
> 
>    1. Build the root filesystem image.
>    2. Run veritysetup over it -> hash tree + a root hash
>    3. Bake the root hash into an initramfs (a separate minimal image 
> from the rootfs).
>    4. Bundle that initramfs into the kernel (INITRAMFS_IMAGE_BUNDLE)
> and 
> assemble the FIT.
> 
> The kernel/FIT task is allowed to depend on an artifact that is
> derived 
> from the finished rootfs image. The root hash is dynamic (only exists
> after the rootfs is built), and it flows into the initramfs, which is
> a 
> distinct artifact from the rootfs being hashed.
> 
> Buildroot has a fixed pipeline:
> 
>      packages (incl. the kernel)  ->  target-finalize  ->
>      filesystem images (rootfs.squashfs, rootfs.cpio, ...) ->  post
> image
> 
> The kernel is built during the package phase, i.e. before any
> filesystem
> image exists. The dm-verity root hash can only be computed after the 
> rootfs image (squashfs) is generated, in the filesystem-image phase.
> To 
> bake that root hash into an initramfs-in-kernel, the kernel would
> have 
> to be (re)built after the rootfs image.
> 
> Buildroots BR2_TARGET_ROOTFS_INITRAMFS's (linux-rebuild-with-
> initramfs)
> doesn't help fully: the root hash isn't known until the squashfs
> exists, 
> there's no ordering between rootfs-cpio and rootfs-squashfs, and no
> hook 
> to rebuild the kernel after a given fs image.
> 
> Our current workaround: a post-image script runs veritysetup, then 
> recursively calls `make linux-rebuild-with-initramfs` with the root
> hash 
> in the environment to re-bake the cpio and re-link the kernel, then 
> rebuilds the FIT. It boots, but needs a recursive `make` from post-
> image 
> and re-link the kernel an extra time per build.
> 
> Questions:
>    1. Is there a supported way, today, to have the kernel (or a FIT)
> be
>       (re)generated after a filesystem image has been produced and
>       post-processed — i.e. to feed a rootfs-image-derived artifact
> back
>       into the kernel/initramfs — without a recursive `make` from a
> post
>       image script?
> 

I think your analysis of the Buildroot pipeline is accurate, and I
don’t believe you are missing an existing “proper” mechanism for this
soo I think the workaround you describe is reasonable given the current
model.

For comparison, our own flow already relies on post-image for final
boot artifact assembly. In our case the post-image script: rearranges
DTs/overlays, compresses the kernel, rebuilds the FIT using mkimage,
runs genimage, and generates .bmap. So conceptually we are already
treating the FIT as a deployment artifact assembled after Buildroot’s
normal image generation phase.

That said, I think there could be alternative approaches worth
considering which may fit Buildroot’s model a bit more naturally.

>    2. If not, is the recursive-`make`-from-post-image pattern
> considered
>       acceptable, or is there a cleaner idiom we are missing.
> 
> 
One possible alternative could be to avoid baking the dm-verity hash
into the kernel-bundled initramfs, and instead provide it externally
(e.g. via cmdline, FIT metadata, or signed manifest)?

Another option may be to keep the initramfs external to the kernel and
generate it only after veritysetup, then assemble/sign the final FIT
from post-image?

> Any guidance or pointers would be helpful and appreciated - including
> if 
> I have overlooked an simple existing mechanism
> 
Honestly, you haven't, as far as I know, so your existing mechanism
could be acceptable but maybe worth attempting something to avoid the
recursive make.

Regards,
Jamie
> 
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot