rpi-eeprom
rpi-eeprom copied to clipboard
raspberrypi
Feature request: Storing additional files in EEPROM
Describe the bug
The recently added cacertder option enables storing a CA Certificate DER encoded file in the EEPROM. This is a really nice feature and conceptually similar to a use case I'm facing: Sometimes, in an IoT fleet a SD card may die (age, temperature, ...) and the cryptographic key material and device configuration stored on it is gone as well. It would be cool if there was an option to store such info in the EEPROM so people could just put in a new SD card, use automatic HTTP boot to write an SD card image, then the newly written SD card image could restore device-specific data.
Alternatives: Non-key configuration data could theoretically be retrieved via https by the newly written image, however making cryptographic keys available for download is not exactly a best practice.
A single file with 4-8 kB size would suffice in my case (archive of keys+config).
Steps to reproduce the behaviour
Let a SD card die, use a blank SD card to re-provision a Pi 4B based IoT device via the awesome HTTP boot feature.
Device (s)
Raspberry Pi 4 Mod. B
Bootloader configuration.
[all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0
On some devices, IMAGER_REPO_URL is set to provide a custom image for writing to the SD card.
System
No response
Bootloader logs
No response
USB boot
No response
NVMe boot
No response
Network (TFTP boot)
No response
Not the requested solution, but the boot loader config supports comments afaik, so you could embed it as a base64 blob in there like this:
# f00base64doobdedoob
Yes mime-encoded blobs in the config file is the way to go here. Arbitrary user-data blobs in the SPI firmware was been ruled out because it limits the ability to do A/B booting and adds a lot of complexity to upgrades. However, we might be able to increase the config size limit to 16KB on Pi5 without too much difficulty.
Yes mime-encoded blobs in the config file is the way to go here. Arbitrary user-data blobs in the SPI firmware was been ruled out because it limits the ability to do A/B booting and adds a lot of complexity to upgrades. However, we might be able to increase the config size limit to 16KB on Pi5 without too much difficulty.
Thanks @dividuum @timg236 , I will try that.
So something like sudo rpi-eeprom-config --edit at runtime, and then store base64 comment blobs in that file?
What's the maximum allowable size of the eeprom bootloader configuration file?
If I'm using secure boot with rpi-sb-provisioner on a CM5 will the eeprom bootloader config file be vulnerable to extraction when the system is off?
There are no plans to support arbitrary user data storage in the SPI EEPROM because there is no space left on Pi4 family and on Pi5 the space is already reserved for other features such as A/B booting.
I think we can reserve a single page for the EEPROM config (4KB) on Pi4 / Pi5, alhtough there's some work required to free up enough space for 4KB on Pi4.
on Pi5 the space is already reserved for other features such as A/B booting.
Interesting. Does that mean that the data in the EEPROM itself will have an A/B flow someday in the future? Right now ~680KB of 2MB are used? Is the 2MB then maybe split in half for the A/B versions?
alhtough there's some work required to free up enough space for 4KB on Pi4.
I'm guessing improving the RLE compression? When I use https://git.venev.name/hristo/rpi-eeprom-compress, the bootmain alone shrinks from 242404 to 239684 bytes while decompression still produces the same SHA256 in the Python only decompression I toyed around with.
In A/B mode the EEPROM is split into three sections. A/B plus a small (perhaps 128K maybe smaller) immutable loader area and the A/B flag / meta-data. We may use LZ4 compression to improve this a bit further which should do better than the RLE.
It's on the roadmap but not very soon, there's some higher priority items related to OS A/B watchdogs etc in progress