pothos
commented
1 year ago We could also make the embedding of the hash into the final kernel image a bit nicer - instead of writing it at this magic offset on top of some string data, rather add it in an additional initrd cpio and let the initrd dm-verity setup get it from there.
Current situation
The kernel parameters are set up by GRUB and used to initiate the first boot logic and setup dm-verity with the right partition and hash. In the past GRUB also passed a parameter to initiate the GPT disk ID randomization but we moved that step to the initramfs because the implementation in GRUB caused some hardware to hang.
Impact
The kernel parameters vary on each update and from first boot to second boot which makes it hard to rely on the kernel parameters for measuring the boot for remote attestation. In case of needed GRUB changes users have to install a image because A/B updates don't cover GRUB.
Ideal future situation
The initramfs checks for the first boot flag file on the boot disk and does not rely on GRUB to set it. The initramfs finds the matching A/B partition and hash itself. New versions of our GRUB setup don't pass the kernel parameters for anymore, i.e., no
BOOT_IMAGE=/flatcar/vmlinuz-b verity.usr=PARTUUID=... verity.usrhash=....Implementation options
The initramfs could compare the embedded verity hash of the loaded kernel with the embedded verity hashes of the A/B kernels on the boot disk to determine whether partition A or B should be mounted. Relying on the GPT attributes would be possible but it doesn't cover the case where the user manually selects to boot the old kernel in the GRUB menu.
Additional information
dd if=/boot/flatcar/vmlinuz-a conv=notrunc skip=64 count=64 bs=1 status=nonegives the hash for amd64, arm64 needsskip=512