oversized secure-boot ramdisk silently truncated #375
Comments
|
Thanks. Yes, there should be an explicit error message for this so we'll add that. The current limit as you say is 64MB, maybe 128MB could be supported although the signature check will be a bit slow. There's some wiggle room in the memory map but I don't want to commit to things that will cause headaches in the future until the use-cases are better understood. |
|
for context, my initrd is 50mb but i can see 2 ways i could optimize my end |
|
The latest beta-release (also in usbboot) should help here. The limit is increased to 96MB and some of the error messages have been improved |
|
Thank you for increasing the limit. I am using unsigned/non-secure images and really had problems with the 64MB limit. |
|
Hmm, @timg236 it seems that the new limit somehow doesn't apply.. I still says this in dmesg and just truncates the image after 64MB: The |
|
@ibot3 this ticket is about the firmware ramdisk, but your error message looks like a linux ramdisk, which doesnt have a size limit when the firmware ramdisk gets truncated, that also changes the hash, causing the signature to be invalid, so it wont even boot |
|
Okay, sorry. Then I just misunderstood something. However, there seems to be a limit of 64MB which is really annoying: But I don't know where this limit is applied. But I should probably create an other issue for this (I just dk where). |
|
It's 96MB and it's applied by the bootloader - the logging should indicate this more clearly. That's still pretty big for a ramdisk that should only include kernel, start.elf and minimal initrd for secure-boot |
|
I am using the initrd to store a minimal bootstrapped debian in it which is around 300MB uncompressed. It's working fine as long as the initrd is below 64MB. But if that's not the case, the initrd seems to get truncated which causes a corrupted system, because important files are missing. I am using netboot for this by the way. |
|
There's no benefit in including all the start.elf variants or bootcode.bin. N.B. The purpose of the ramdisk is just to bootstrap secure-boot and not provide alternate methods for running Linux from memory e.g. you could use NFS to load the root filesystem |
|
Okay I found a guide which uses an cow-overlayfs with an ro NFS: https://blockdev.io/read-only-rpi/ But imo the We have 30+ PoE powered pis and I just want to be able to create a new image and just restart all pis to keep them up to date. So would there be a way to increase this limit of 64MB? |
|
If you use the latest beta EEPROM 2021-11-22 then the limit is 96MB. I think in the future we might be able to go as high as 256MB assuming you can tolerate the load time. However, there's a few memory map things that we'd need to think through first e..g. conflicting with large amounts of GPU memory and random Kernel load addresses i.e. not a very short term fix |
|
Closing since this the limit was increased to 96MB in the stable release. Larger RAM disks might be supported in future but will probably have the caveat that GPU memory will be automatically reduced instead. That should be ok because KMS + libcamera mostly remove the need for GPU memory. |
|
@timg236 So there still seems to be some limit of 64MB and I don't understand where it comes from. However I am using |
|
If it's getting that far it's unlikely to be a bootloader issue. It might be worth updating the latest start.elf file. I'm currently using an 80MB with a 69MB rootfs.cpio.zst initrd |
|
@timg236 I seem to be running into the same issue as @ibot3 with PXE boot of Pi 4 model B 8GB. Specifically, I am trying to boot with an 86MB initrd and it appears to be truncated. I have the latest stable eeprom (2022-09-02) with When you say that you are currently using 80MB initrd, is this via PXE or from SD/USB? If the latter, perhaps there is something specific to the network boot that's going on here? For completeness, here is my Let me know if you need any additional information or have any hints. |
|
Recent firmwares support a new setting - sha256. Non-zero values enable the calculation and display of SHA256 digests for loaded files (as calculated by sha256sum). Note that this can really slow down the boot process, but it will help to confirm or rule out corruption. |
|
https://www.raspberrypi.com/documentation/computers/config_txt.html#sha256 for (slightly) more info. |
|
@pelwell @lurch Thanks for the suggestion though I don't see the checksums anywhere in the serial console output. Specifically, I have The observations that I can make from this:
|
|
Ah - you'll need |
|
@pelwell Thanks, that definitely gave more information (continuing after the So the size reported ( Let me know if you need any more information from my side. |
|
0x3fffc00 equates to 65535 x 1024. According to what I found on Wikipedia, the TFTP protocol is limited to 65535 (0xffff) blocks, each of which can hold up to 65535 bytes. However, the implementation in the EEPROM has It does seem as if larger files can't be downloaded without that |
|
Interesting. Do you think |
|
The bootloader isn't loading the initrd in this case, it's loaded by start4.elf. I think it's unlikely that the ethernet max packet size would be increased though. |
|
I think a better alternative would be to use BOOT_ORDER_HTTP and package all of the boot files into a boot.img. This also has the advantage that boot.img files can be signed and at some pointer we'll probably add support for HTTPS (assuming we can find space for cutdown certifcate store) |
|
@pelwell / @timg236 Is it worth mentioning this maximum TFTP file-size limitation in our documentation? |
|
Is it worth asking the question? |
|
Minor point, this TFTP discussion is nothing to do with issue posted by the OP which was about the boot.img ramdisk that was limited to 64MB |
…ning block firmware: arm_loader: Raise maximum gzipped kernel size firmware: arm-loader: Indicate tryboot status via /proc/device-tree/chosen/bootloader/tryboot firmware: arm_loader: Increase TFTP block size to 1468 bytes See: raspberrypi/rpi-eeprom#375 firmware: Add kernel= logging firmware: camera_auto_detect changes See: #1750
…ning block firmware: arm_loader: Raise maximum gzipped kernel size firmware: arm-loader: Indicate tryboot status via /proc/device-tree/chosen/bootloader/tryboot firmware: arm_loader: Increase TFTP block size to 1468 bytes See: raspberrypi/rpi-eeprom#375 firmware: Add kernel= logging firmware: camera_auto_detect changes See: raspberrypi/firmware#1750
|
@boris-kolpackov It looks like with the latest firmware and beta EEPROM the maximum initrd size is now 91MB. |
|
@lurch Thanks, will give it a try when get a chance and report back. |
|
Now that the release is available I'm locking this bug. The TFTP issue is orthogonal to the boot.img size and it's confusing to have a github issue tracking two different things even if they are superficially similar. |
Mandatory information
Describe the bug
if the boot.img file is over 64mb, it will silently be truncated to 64mb, and then fail the boot.sig validation
To Reproduce
create a properly signed boot.img that is 100mb in size
Expected behaviour
at a bare minimum, report that it is too big on the uart logs, so other users dont have to decompile just to find the size limit
the size limit should also be documented and checked in the scripts for building the image, they currently warn for >20mb, but dont tell you that >64mb wont work
ideally, have a more dynamic buffer size, but i can see that being difficult
Bootloader version and configuration
RPi: BOOTLOADER release VERSION:a6afaeaa DATE: Oct 5 2021 TIME: 08:53:57 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1633420437 0xd328cdce 0x00c03112 0x0006f72cAdditional context
Add any other context about the problem here.
yes, the signature is valid, it fails with a 100mb image, but works with a 64mb image, signed using the same directions and key
The text was updated successfully, but these errors were encountered: