Currently, secure-boot is typically used with lightweight buildroot images for embedded applications. Typically a read-only rootfs that runs an application e.g. docker from an encrypted rootfs.
Enabling secure-boot instructs the firmware to load files from a signed boot.img ramdisk instead of the boot partition. This must contain at least config.txt, kernel, device-tree plus optionally initramfs and overlays.
A simple example based on the mass-storage-gadget buildroot is available here.
https://github.com/raspberrypi/buildroo ... README.md
The sign.sh script for the mass-storage-gadget64 can be used to sign boot.img
https://github.com/raspberrypi/usbboot/ ... d-bcm2712
Right now, this is the only example for Pi5. It's a good starting point for exploring secure-boot.
However, I would re-iterate (for other users) that the first step for secure-boot is to get the OS running from a boot.img ramdisk before locking the Pi into secure-boot mode by programming the OTP.
Enabling secure-boot instructs the firmware to load files from a signed boot.img ramdisk instead of the boot partition. This must contain at least config.txt, kernel, device-tree plus optionally initramfs and overlays.
A simple example based on the mass-storage-gadget buildroot is available here.
https://github.com/raspberrypi/buildroo ... README.md
The sign.sh script for the mass-storage-gadget64 can be used to sign boot.img
https://github.com/raspberrypi/usbboot/ ... d-bcm2712
Right now, this is the only example for Pi5. It's a good starting point for exploring secure-boot.
However, I would re-iterate (for other users) that the first step for secure-boot is to get the OS running from a boot.img ramdisk before locking the Pi into secure-boot mode by programming the OTP.
Statistics: Posted by timg236 — Thu May 02, 2024 3:41 pm