Re: [yocto] Secure Boot and LUKS-encrypted rootfs on Raspberry Pi CM4

Hi,

On Mon, Oct 13, 2025 at 03:39:56PM +0000, Benjamin Marty via lists.yoctoproject.org wrote:
> Hello all
> 
> I have an A/B system running on a Raspberry Pi CM4 using the tryboot_a_b mode from the Raspberry Pi Firmware (via the https://github.com/agherzan/meta-raspberrypi layer).
> 
> I’m now exploring how to implement Secure Boot using the Raspberry Pi Firmware (without U-Boot) and have run into a few design challenges:
> - The files on the boot partition (cmdline.txt, config.txt, kernel8.img, initramfs etc.) need to be packed into a boot.img file using the Raspberry Pi script https://github.com/raspberrypi/usbboot/blob/master/tools/rpi-make-boot-image. I believe this could be integrated with a .bbclass file.
> - The resulting boot.img file then needs to be signed using https://github.com/raspberrypi/rpi-eeprom/blob/master/rpi-eeprom-digest, which could also be handled through a .bbclass file.
> - Both rootfs partitions (A/B) should be LUKS-encrypted, unlocked during boot via an initramfs. This seems like the biggest challenge, I'm not sure if this is even possible with WIC, especially because the key for the partition needs to be device-specific.
> 
> Has anyone worked on something similar, or have pointers on how to best approach this?

I would abstract away from LUKS a bit. What is usually needed is
data which is signed but shared across all devices and then data
and/or storage which unique and protected on each device seprately.
Thus somewhere on each device there is a device specific secret
which is used to create device specific keys and encrypted storage.

Once you have secure boot from HW to a Linux kernel and initramfs
on a device, I would split the common read-only mass storage, e.g.
rootfs, to a dm-verity partition which can be created by yocto
into a wic image. The dm-verity root hash can be bound into
e.g. UKI image with kernel, kernel command line and initrd which
are signed with secureboot keys which the firmware always verifies.
For non-UEFI firmware there must be ways to achieve the same.

Then the device specific protected storage can be created with a TPM.
For example systemd-repart in the initrd can be configured to create
a TPM backed encrypted storage with even variable size. Depending on
the TPM PCR policy this can 'measure' the boot and make sure that decrypting
the storage only works if boot binaries were correct, or the default
which AFAIK ties the encrypted storage to UEFI secureboot keys, which allows
changes and updates to the kernel, initrd, rootfs etc. If there is no
HW TPM device available, it may be an option to use OP-TEE and firmware
TPM (fTPM) TA, but that also depends on RPMB secure storage support
which needs to be available.

Sample systemd-repart config is here:
https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/systemd_uki/meta-ledge-secure/recipes-core/systemd/systemd-repart-conf.bb?ref_type=heads#L21

Hope this helps.

Cheers,

-Mikko