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

Hello,

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?

   2. If not, is the recursive-`make`-from-post-image pattern considered
      acceptable, or is there a cleaner idiom we are missing.


Any guidance or pointers would be helpful and appreciated - including if 
I have overlooked an simple existing mechanism

Thanks in advance.

-- 
Thanks and Regards,
Manikandan M.

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