Open SyedFaisalAli opened 1 month ago
ramdisk is set in config, the boot.img (Tested around 60MB) is able to be read and kernel loads, however, the initramfs fails to load and continues to main root partition. Below 30MB, the kernel and initramfs shell successfully loads.
Hi. To avoid any doubt, for both signed and signed boot scenarios, please state if your initramfs archive is embedded into the kernel image (image is a single monolithic blob), or if it's stored as a separate file (kernel and initramfs are separate)?
To verify if authentication is working correctly on a monolithic blob, you could create a file containing random data of a certain size, sign it, then check if the bootloader authenticates it upon load.
Hi!
Hi. To avoid any doubt, for both signed and signed boot scenarios, please state if your initramfs archive is embedded into the kernel image (image is a single monolithic blob), or if it's stored as a separate file (kernel and initramfs are separate)?
The Initramfs archive is stored as a separate file within boot.img. I forgot to show my config.txt in boot.img:
enable_uart=1
uart_2ndstage=1
disable_overscan=1
dtoverlay=dwc2,dr_mode=peripheral,nohdmi
start_file=start4.elf
fixup_file=fixup4.dat
initramfs initramfs.cpio.xz followkernel
Outer config in boot partition:
enable_uart=1
boot_ramdisk=1
uart_2ndstage=1
To verify if authentication is working correctly on a monolithic blob, you could create a file containing random data of a certain size, sign it, then check if the bootloader authenticates it upon load.
So, I created a 30MB file and signed:
dd if=/dev/urandom of=boot.img bs=1024 count=30000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem
After copying to the boot partition in our nvme stick, it verifies successfully:
43.37 secure-boot
43.39 Loading boot.img ...
43.42 boot.sig
43.43 hash: 01d752b596c5c8d277482a4e93b2e77f26cd2e3106363a91e67033e55eeddf9c
43.50 ts: 1729176130
43.52 rsa2048: 49adf45767915153ab089e886cd2e9bc4e88f5074f7b333c09b84d17f317fb08968216daee2a0d448b1
dc80ab267cdbddc8eae890724c95257c1d6bbe9aeb38a2a3f65813177f3c06e5e4e5b671b0ab16aa6ce8df895509ee1bffe
144b963093bbbe3c7907168aa6015015d1a7692fff1044edc11775c017d08f3ff3ddf0f8c398a04e30f9705a1570521a28d
17643beec93a13061f2e32b697aa4d3fb7757975d1f8fd006dcb8212034d03956cf9128e571d39335fc90a4e22a2192fcfd
b24c456e8b177f81bb9306a91d7b7d56d81bee712a47abd6516e2c7d700c1dbeff066132f8bfaf944fa0d98896eac4b91c7
05d63818ac1e2c9e07fa4a461b585ea7f
44.14 Verifying
47.07 RSA verify
47.19 rsa-verify pass (0x0)
I then create a 31MB file and sign:
dd if=/dev/urandom of=boot.img bs=1024 count=31000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem
Fails to load with bad signature.
134.69 type: 16 lba: 16384 'mkfs.fat' ' V ^ ' clusters 42551 (8)
134.75 rsc 8 fat-sectors 168 root dir cluster 1 sectors 32 entries 512
134.82 FAT16 clusters 42551
134.84 secure-boot
134.86 Loading boot.img ...
134.89 boot.sig
134.90 Failed to parse signature file
134.93 Bad signature boot.sig
134.96 Error 12 loading boot.img
Your original description seems different to the 31 MB test, though.
6.27 Loading boot.img ...
6.30 boot.sig
...
7.47 Verifying
14.00 Bad signature boot.img
14.54 Error 12 loading boot.img
vs
134.86 Loading boot.img ...
134.89 boot.sig
134.90 Failed to parse signature file
134.93 Bad signature boot.sig
134.96 Error 12 loading boot.img
The actual authentication check of the image doesn't look like it actually happened.
I just tried the 31MB image on a 2024/09/23 bootloader using the same command as you and it worked fine on SD, USB, NVMe
dd if=/dev/urandom of=boot.img bs=1024 count=30000
rpi-eeprom-digest -i boot.img -o boot.sig -k private.pem
Possibly a mismatch in the key or an issue with the NVMe.
It might be worth updating the bootloader and replacing the mass-storage-gadget64/boot.img file to see if you can still reproduce the issue.
Hi all, thanks so far!
Yes, it looks like I was mistaken (I might not have synced or copied the signature file correctly the second time). So, at 31M, the boot.img passed.
I'm trying higher sizes now by increasing every 10M. Just on the NVMe, this is the results I'm seeing, but I'll try the SDCard as well to see if there's any issue with the nvme on my end.
dd if=/dev/urandom of=boot.img bs=1024 count=31000 # Passed
dd if=/dev/urandom of=boot.img bs=1024 count=40000 # Passed
dd if=/dev/urandom of=boot.img bs=1024 count=50000 # Failed with Bad signature boot.img
It might be worth updating the bootloader and replacing the mass-storage-gadget64/boot.img file to see if you can still reproduce the issue.
Will update the bootloader as well. Last I tried mass-storage-gadget64/boot.img
, it did load. The default image in the repo is about 30MB, but I don't believe I tried replacing it.
It turns out, the boot partition flashed to the nvme from our Yocto WIC image was not set up to format with FAT32, defaulting to FAT16 instead. This was the major difference after comparing with the Raspberry Pi Imager, which flashed its boot partition on the nvme with FAT32, and allowed loading of a larger boot.img without issue.
Oddly, this only mattered for the nvme as we were able to flash our WIC image onto an SDCard with FAT16 formatted boot and load the boot.img. We were also able to load a larger boot.img from USB on our default and the latest eeprom.
In any case, I appreciate the guidance! Feel free to close this ticket if needed.
Describe the bug
This seems similar to https://github.com/raspberrypi/rpi-eeprom/issues/375
The understanding from docs is "The maximum size for a ramdisk file is 96MB", but this appears to be limited to Raspberry Pi4 with observed behavior. On Pi5, a signed boot.img fails to load past 30MB. Below 30MB, the kernel and a small initramfs shell (1.3MB) is successfully loaded from ramdisk.
If the signed boot is disabled but ramdisk is set in config, the boot.img (Tested around 60MB) is able to be read and kernel loads, however, the initramfs fails to load and continues to main root partition. Below 30MB, the kernel and initramfs shell successfully loads.
Some clarifications on the size limits over ramdisk vs signed boot would be helpful. If possible, raising this limit like what was done with 2711 would help allow for bigger initramfs with tools to support LUKS encryption and decryption before main rootfs mounting.
Steps to reproduce the behaviour
Build a signed boot.img greater than 30MB.
Device (s)
Raspberry Pi 5
Bootloader configuration.
System
OS/Version: Yocto-based Kirkstone Distribution Bootloader Version:
Firmware Version:
Kernel Version:
Linux CAM-2CCF67509B94 6.1.77-v8-16k #1 SMP PREEMPT Thu Feb 8 15:07:10 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
Bootloader logs
USB boot
No response
NVMe boot
Network (TFTP boot)
No response