Hello there!
I am, with a lot of help from Claude, working on a secure boot chain for the CM4 with dm-verity. Once I get it working my plan is to untangle it from our proprietary layer and make it into its own, open source layer.
As has been discussed on this forum previously, we need a custom update module that will find the underlying block device, and the dm-verity root hash cannot go on in rootfs (because chicken/egg) nor in a single location (because A/B updates).
Claude proposed a per-slot FIT in boot.img containing the root hash. Which made me think perhaps we should move the kernel into that same file (rather than /boot/fitImage). Thoughts? One disadvantage is that the kernel is not protected by dm-verity but I am not sure this is an issue in practice (I don’t think there’s a splice attack).
In this case the layout would be as follows:
FAT (kernel lives here, per slot)
config.txt 15
boot.img 3,213,312
boot.sig 602
boot.scr 4,756
boot-2.fit 10,848,705
boot-3.fit 10,848,705
109 MB free of 128 MB
boot.fit content summary
FIT description: xebra slot boot (kernel + dtb stub + bootargs script)
Image 0 (kernel) gzip, 10,788,495 B (10.29 MiB) AArch64/Linux load=0x20008000 sha256
Image 1 (fdt) none, 56,928 B (55.59 KiB) AArch64 sha256
Image 2 (script) none, 552 B Script sha256
Default Configuration: 'conf-1'
Configuration 0 (conf-1)
Kernel: kernel
FDT: fdt
(script: script) ← present per fdtget (dumpimage doesn't print it)
Sign algo: sha256,rsa2048:boot_img
Sign padding: pkcs-1.5
sign-images: kernel fdt script ← all three covered by one signature
.mender artifact payload
Type: rootfs-verity
Files:
rootfs.ext4.verity 2,654,769,152 B sha256 e06927fc...
boot.fit 10,848,705 B sha256 81c2d91c...
2 payload files, no separate fitImage. Signature on artifact present.
Cheers,
Luke