rpi-eeprom
rpi-eeprom copied to clipboard
raspberrypi
program_pubkey=1 seems to do nothing ? Can't enable secure boot
Describe the bug
Hello. I used to have a working secure boot working on RPI5. I created a signed pieeprom.upd + sig, put a recovery.bin on the sdcard. That programmed the new EEPROM image and enabled secure boot. Hence forth only a signed boot.img was loaded.
boot.img contains config.txt with program_pubkey=1. That should write the key to the OTP. Recently however I noticed that my Customer key hash is still 0000000000000000000000000000000000000000000000000000000000000000. And sure enough, the public recovery.bin could still run and write an EEPROM image that disabled secure boot.
I was really confused because I have one rpi5 that has the Customer key written and I did it the same way, I never tried any other boot other than from SD card. On that RPI I can only run my own counter signed recovery.bin and I cannot disable secure boot anymore.
I looked at my history and found some logs I haven't seen in a long long while... I wonder why
SIG pieeprom.sig <hash> 1724505847
Reading EEPROM: 2097152 bytes 0xc1160000
2483ms
Bootloader EEPROM is up to date
RSA verify
rsa-verify pass (0x0)
Public key hash <hash>
OTP updated for key <hash>
rename recovery.bin to RECOVERY.000
'RECOVERY.000' already exists
rename recovery.bin to RECOVERY.001
Did I have some build of recovery.bin that prints on UART and now I have one that doesn't ? strange.
In any case, I though I'll just use latest code, i've pulled the entire usbboot repo and noticed updates to the rpi-eeprm and secure boot related tools. They mention, that the SECURE_BOOT=1 flag was removed from eeprom boot.conf file.
With the latest eeprom firmware and the signing script i got a new pieeprom.upd, i've programmed it and now the secure boot doesn't work at all. Seems like I have a completely stock rpi that can boot any unsigned boot.img. Any idea what is going on ? Is enabling secure boot from the pi itself not supported anymore ? Was I using some beta release that could do it ? That's how it looks like to me.
Steps to reproduce the behaviour
Sign an EEPROM image like this Readme says https://github.com/raspberrypi/usbboot/blob/master/secure-boot-recovery5/README.md Write EEPROM using recovery.bin Run boot.img with config.txt that contains program_pubkey=1 Secure boot should be enabled, key written to OTP. But it never happens.
Device (s)
Raspberry Pi 5
Bootloader configuration.
The "old" eeprom config that enables secure boot but doesn't seem to write the key to OTP
[all]
BOOT_UART=1
POWER_OFF_ON_HALT=1
# Boot Order Codes, from https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER
# Try SD first (1), followed by, USB (RP1), NVMe PCIe, then network
BOOT_ORDER=0xf6241
# Disable self-update mode - to prevent automatic updates of unsigned bootloader images
ENABLE_SELF_UPDATE=0
# Select signed-boot mode in the EEPROM. This can be used to during development
# to test the signed boot image. Once secure boot is enabled via OTP this setting
# has no effect i.e. it is always 1.
SIGNED_BOOT=1
The new config, default from https://github.com/raspberrypi/usbboot/blob/master/secure-boot-recovery5/boot.conf
[all]
BOOT_UART=1
POWER_OFF_ON_HALT=1
# Boot Order Codes, from https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER
# Try SD first (1), followed by, USB (RP1), NVMe PCIe, then network
BOOT_ORDER=0xf2461
# Disable self-update mode - to prevent automatic updates of unsigned bootloader images
ENABLE_SELF_UPDATE=1
System
Using my own Yocto build
Bootloader logs
old eeprom firmware
0.37 RPi: BOOTSYS release VERSION:6fe0b091 DATE: 2024/06/05 TIME: 16:41:49
0.41 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1717602109 serial 2c436215 boardrev b04170 stc 841879
0.51 AON_RESET: 00000003 PM_RSTS 00000020
0.59 RP1_BOOT chip ID: 0x20001927
0.61 PM_RSTS: 0x00000020
0.62 part 00000000 reset_info 00000000
0.65 PMIC reset-event 00000000 rtc 67ec5446 alarm 00000000 enabled 0
0.72 uSD voltage 3.3V
0.91 Initialising SDRAM 'Micron' 16Gb x1 total-size: 16 Gbit 4267
0.94 DDR 4267 0 0 16 152
2.38 OTP boardrev b04170 bootrom a a
2.39 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
2.46 VC-JTAG unlocked
2.69 RP1_BOOT chip ID: 0x20001927
2.74 RP1_BOOT chip ID: 0x20001927
2.75 RP1_BOOT: fw size 25992
3.30 PCI2 init
3.30 PCI2 reset
3.75 PCIe scan 00001de4:00000001
3.75 RP1_CHIP_INFO 20001927
3.78 RPi: BOOTLOADER release VERSION:6fe0b091 DATE: 2024/06/05 TIME: 16:41:49
3.85 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1717602109 serial 2c436215 boardrev b04170 stc 3185426
3.95 AON_RESET: 00000003 PM_RSTS 00000020
3.99 PCIEx1: PWR 0 DET_WAKE 0
3.02 M.2 PCIe HAT not detected.
3.26 usb_pd_init status 3
3.26 USB_PD CONFIG 0 43
3.29 Boot mode: SD (01) order f24
3.45 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
3.56 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
3.19 OCR c0ff8000 [87]
CID: 0002544d53413332477849e4a084017c
CSD: 400e00325b590000e8977f800a400000
3.27 SD: bus-width: 4 spec: 2 SCR: 0x02058083 0x01000000
3.35 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
3.44 MBR: 0x00000800, 415744 type: 0x0e
3.46 MBR: 0x00080000,60448768 type: 0x83
3.50 MBR: 0x00066000, 40960 type: 0x0e
3.54 MBR: 0x00070000, 40960 type: 0x0e
3.58 Trying partition: 0
3.61 type: 16 lba: 2048 'mkfs.fat' ' V ^ ' clusters 51911 (8)
3.66 rsc 8 fat-sectors 208 root dir cluster 1 sectors 32 entries 512
3.73 FAT16 clusters 51911
3.77 [sdcard] autoboot.txt not found
3.79 Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 0
3.85 Trying partition: 0
3.89 type: 16 lba: 2048 'mkfs.fat' ' V ^ ' clusters 51911 (8)
3.94 rsc 8 fat-sectors 208 root dir cluster 1 sectors 32 entries 512
3.01 FAT16 clusters 51911
3.03 secure-boot
3.05 Loading boot.img ...
3.08 boot.sig
3.09 hash: 6032426592a058d637e2757438ca81043b834ac6bcfee1ebfe67c7f35e96e3eb
3.16 ts: 1743541284
3.18 rsa2048: 20e109e4b2f29211c13a106e1db63ab19cac53e6b287b178a58e188005f3d510f38607fb7bb9bc21ea5306fc996d28ee4d5fbcc44f50edb5fc2a49145a4d4f0106859d7fab45aa27c6cf5c59cccb29137d89d843a07dc6b8688684432b1fe515c30bb0ba7200cc9635e37dde6517e3390e0cc6e3e864a8a5fcb0f813cf51aa59079abd681d971f09e682f63edd11ce51cfbb25dc9545aecf50371952598f0fd2b7dde64134ddc09cf6e68fafb2980e9fbe30d3bb252dbae32f4776849eb25ec1a279ceeab20fbcfa3c7acb2c1fdf1d8824a5fad706c28266dbc65d39354213c8607b90a29bc9611f2bada148b66be08a5f26de596bcc6d1d92464aba5d66a7aa
3.87 Verifying
4.58 RSA verify
4.70 rsa-verify pass (0x0)
4.85 MBR: 0x00000000, 0 type: 0x00
4.86 MBR: 0x00000000, 0 type: 0x00
4.90 MBR: 0x00000000, 0 type: 0x00
4.93 MBR: 0x00000000, 0 type: 0x00
4.97 Trying partition: 0
4.00 type: 12 lba: 0 'mkfs.fat' ' V ^ ' clusters 2553 (4)
4.06 rsc 4 fat-sectors 8 root dir cluster 1 sectors 16 entries 256
4.12 FAT12 clusters 2553
4.15 Read config.txt bytes 291 hnd 0x47
4.18 usb_max_current_enable forced to 1
4.24 Read bcm2712-rpi-5-b.dtb bytes 82227 hnd 0x3
4.27 dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
4.33 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
4.41 Read /config.txt bytes 291 hnd 0x47
4.44 Read /config.txt bytes 291 hnd 0x47
4.51 MESS:00:00:04.350989:0: Initial voltage 800000 temp 43325
4.51 MESS:00:00:04.551406:0: avs_2712: AVS pred 8690 869000 temp 42776
4.55 MESS:00:00:04.555010:0: vpred 869 mV +0
5.34 MESS:00:00:05.434088:0: FB framebuffer_swap 1
5.53 MESS:00:00:05.453657:0: Select resolution HDMI0/2 hotplug 0 max_mode 2
5.57 MESS:00:00:05.457706:0: Select resolution HDMI1/2 hotplug 0 max_mode 2
5.74 MESS:00:00:05.474188:0: dtb_file 'bcm2712-rpi-5-b.dtb'
5.76 Loading 'bcm2712-rpi-5-b.dtb' to 0x00000000 offset 0x100
5.83 Read bcm2712-rpi-5-b.dtb bytes 82227 hnd 0x3
5.09 Read /overlays/overlay_map.dtb bytes 5195 hnd 0x168
5.17 Read /overlays/bcm2712d0.dtbo bytes 1491 hnd 0x284
5.42 MESS:00:00:05.542343:0: Loaded overlay 'bcm2712d0'
5.24 PCIEx1: PWR 0 DET_WAKE 0
5.37 MESS:00:00:05.637884:0: Found camera 'imx477' on port 0, unicam_port 0
5.43 Read /overlays/imx477.dtbo bytes 3527 hnd 0x190
5.10 MESS:00:00:05.710588:0: Loaded overlay 'imx477'
5.23 Read /config.txt bytes 291 hnd 0x47
5.26 Read /overlays/vc4-kms-v3d-pi5.dtbo bytes 3330 hnd 0x1af
5.70 MESS:00:00:05.870066:0: Loaded overlay 'vc4-kms-v3d-pi5'
5.72 Read /overlays/gpio17.dtbo bytes 315 hnd 0x41e
5.83 MESS:00:00:05.983243:0: Loaded overlay 'gpio17'
6.00 Read /overlays/uart3-pi5.dtbo bytes 627 hnd 0x3ea
6.18 MESS:00:00:06.018214:0: Loaded overlay 'uart3-pi5'
6.20 MESS:00:00:06.020527:0: dtparam: uart0=on
6.13 Read /cmdline.txt bytes 44 hnd 0x46
6.33 BMD "armstub8-2712.bin" not found
6.34 fs_open: 'armstub8-2712.bin'
6.37 Loading 'kernel_2712.img' to 0x00000000 offset 0x200000
6.48 Read kernel_2712.img bytes 587256 hnd 0x48
6.50 PCI1 reset
6.61 PCI2 reset
6.71 USB-OTG disconnect
7.10 MESS:00:00:07.410232:0: Starting OS 7410 ms
7.14 MESS:00:00:07.414541:0: 00000040: -> 00000480
7.16 MESS:00:00:07.416639:0: 00000030: -> 00100080
7.21 MESS:00:00:07.421352:0: 00000034: -> 00100080
7.26 MESS:00:00:07.426064:0: 00000038: -> 00100080
7.30 MESS:00:00:07.430778:0: 0000003c: -> 00100080
NOTICE: BL31: v2.6(release):v2.6-239-g2a9ede0bd
NOTICE: BL31: Built : 14:26:57, Jun 22 2023
U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
new eeprom firmware
0.54 RPi: BOOTSYS release VERSION:2bb2ae64 DATE: 2025/03/10 TIME: 17:10:37
0.58 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1741626637 serial 2c436215 boardrev b04170 stc 858883
0.68 AON_RESET: 00000003 PM_RSTS 00001000
0.72 POWER_OFF_ON_HALT: 1 WAIT_FOR_POWER_BUTTON 0 power-on-reset 1
0.82 RP1_BOOT chip ID: 0x20001927
0.86 PCIEx1: PWR 0 DET_WAKE 0
0.87 part 00000000 reset_info 00000000
0.90 PMIC reset-event 00000000 rtc 00000000 alarm 00000000 enabled 0
0.96 uSD voltage 3.3V
1.15 Initialising SDRAM rank 1 total-size: 16 Gbit 4267 (0x06 0x00)
1.19 DDR 4267 0 0 16 152 BL:1
2.84 OTP boardrev b04170 bootrom a a
2.85 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
2.93 VC-JTAG unlocked
2.15 RP1_BOOT chip ID: 0x20001927
2.49 RP1_BOOT chip ID: 0x20001927
2.49 RP1_BOOT: fw size 46888
3.87 PCI2 init
3.87 PCI2 reset
3.32 PCIe scan 00001de4:00000001
3.32 RP1_CHIP_INFO 20001927
3.35 RPi: BOOTLOADER release VERSION:2bb2ae64 DATE: 2025/03/10 TIME: 17:10:37
3.42 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1741626637 serial 2c436215 boardrev b04170 stc 3542300
3.52 PCIEx1: PWR 0 DET_WAKE 0
3.55 M.2 PCIe HAT not detected.
3.79 usb_pd_init status 3
3.79 USB_PD CONFIG 0 41
3.85 XHCI-STOP
3.85 xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
3.90 USBSTS 1
3.92 xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
3.97 xHC0 ports 3 slots 64 intrs 4
3.09 XHCI-STOP
3.09 xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
3.14 USBSTS 11
3.17 xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
3.22 xHC1 ports 3 slots 64 intrs 4
3.29 Boot mode: SD (01) order f24
3.30 USB2[1] 000206e1 connected
3.83 USB2[1] 00200e03 connected enabled
3.84 USB2 root HUB port 1 init
3.92 DEV [01:00] 2.16 000000:01 class 9 VID 05e3 PID 0610
3.94 HUB init [01:00] 2.16 000000:01
3.37 USB3[3] 002a1203 connected enabled
3.38 USB3 root HUB port 3 init
3.43 DEV [02:00] 3.00 000000:03 class 9 VID 05e3 PID 0616
3.46 HUB init [02:00] 3.00 000000:03
4.48 USB-PD: src-cap PDO object1 0x0a0191f4
4.49 Current 5000 mA
4.51 Voltage 5000 mV
4.53 USB-PD: src-cap PDO object2 0x0002d12c
4.57 Current 3000 mA
4.59 Voltage 9000 mV
4.61 USB-PD: src-cap PDO object3 0x0003c0e1
4.65 Current 2250 mA
4.68 Voltage 12000 mV
4.70 USB-PD: src-cap PDO object4 0x0004b0b4
4.74 Current 1800 mA
4.76 Voltage 15000 mV
4.92 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
4.03 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
4.58 OCR c0ff8000 [72]
CID: 0002544d53413332477849e4a084017c
CSD: 400e00325b590000e8977f800a400000
4.66 SD: bus-width: 4 spec: 2 SCR: 0x02058083 0x01000000
4.74 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
4.83 MBR: 0x00000800, 415744 type: 0x0e
4.85 MBR: 0x00080000,60448768 type: 0x83
4.89 MBR: 0x00066000, 40960 type: 0x0e
4.93 MBR: 0x00070000, 40960 type: 0x0e
4.97 Trying partition: 0
4.00 type: 16 lba: 2048 'mkfs.fat' ' V ^ ' clusters 51911 (8)
4.05 rsc 8 fat-sectors 208 root dir cluster 1 sectors 32 entries 512
4.12 FAT16 clusters 51911
4.16 Read autoboot.txt bytes 64 hnd 0x424d
4.19 Select partition rsts 0 C(boot_partition) 3 EEPROM config 0 result 3
4.25 Trying partition: 3
4.29 type: 16 lba: 417792 'mkfs.fat' ' V ^ ' clusters 10208 (4)
4.34 rsc 4 fat-sectors 40 root dir cluster 1 sectors 32 entries 512
4.41 FAT16 clusters 10208
4.45 Read config.txt bytes 38 hnd 0x604
4.47 Loading boot.img ...
4.25 Read boot.img bytes 4078592 hnd 0x3
4.41 MBR: 0x00000000, 0 type: 0x00
4.42 MBR: 0x00000000, 0 type: 0x00
4.46 MBR: 0x00000000, 0 type: 0x00
4.49 MBR: 0x00000000, 0 type: 0x00
4.53 Trying partition: 0
4.56 type: 16 lba: 0 'mkfs.fat' ' V ^ ' clusters 7918 (1)
4.62 rsc 1 fat-sectors 31 root dir cluster 1 sectors 16 entries 256
4.68 FAT16 clusters 7918
4.72 Read config.txt bytes 299 hnd 0x10b
4.75 pieeprom.sig
4.76 hash: 14845bfbec0604f84d961c46266389a9e4897d96560572eea150f0e1e7756bce
4.83 ts: 1743591843
4.46 SELF-UPDATE timestamp current 1743591843 new 1743591843 skip
4.49 usb_max_current_enable forced to 1
4.54 Read bcm2712-rpi-5-b.dtb bytes 82227 hnd 0x2
4.58 dt-match: compatible: raspberrypi,5-model-b match: brcm,bcm2712
4.64 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712
4.72 Read /config.txt bytes 299 hnd 0x10b
4.75 Read /config.txt bytes 299 hnd 0x10b
4.82 MESS:00:00:04.882007:0: Initial voltage 800000 temp 46073
5.82 MESS:00:00:05.082445:0: avs_2712: AVS pred 8704 870400 temp 46622
5.86 MESS:00:00:05.086053:0: vpred 870 mV +0
5.28 MESS:00:00:05.928612:0: FB framebuffer_swap 1
5.48 MESS:00:00:05.948030:0: Select resolution HDMI0/2 hotplug 0 max_mode 2
5.52 MESS:00:00:05.952081:0: Select resolution HDMI1/2 hotplug 0 max_mode 2
5.68 MESS:00:00:05.968739:0: dtb_file 'bcm2712-rpi-5-b.dtb'
5.71 Loading 'bcm2712-rpi-5-b.dtb' to 0x00000000 offset 0x100
5.78 Read bcm2712-rpi-5-b.dtb bytes 82227 hnd 0x2
6.10 Read /overlays/overlay_map.dtb bytes 5195 hnd 0xe6f
6.22 Read /overlays/bcm2712d0.dtbo bytes 1491 hnd 0xa81
6.47 MESS:00:00:06.047373:0: Loaded overlay 'bcm2712d0'
6.22 PCIEx1: PWR 0 DET_WAKE 0
6.36 MESS:00:00:06.136092:0: Found camera 'imx477' on port 0, unicam_port 0
6.47 Read /overlays/imx477.dtbo bytes 3527 hnd 0xe01
6.13 MESS:00:00:06.213013:0: Loaded overlay 'imx477'
6.26 Read /config.txt bytes 299 hnd 0x10b
6.34 Read /overlays/vc4-kms-v3d-pi5.dtbo bytes 3330 hnd 0xd9c
6.77 MESS:00:00:06.377268:0: Loaded overlay 'vc4-kms-v3d-pi5'
6.76 Read /overlays/gpio17.dtbo bytes 315 hnd 0x588
6.87 MESS:00:00:06.487096:0: Loaded overlay 'gpio17'
6.02 Read /overlays/uart3-pi5.dtbo bytes 627 hnd 0x628
6.20 MESS:00:00:06.520036:0: Loaded overlay 'uart3-pi5'
6.22 MESS:00:00:06.522349:0: dtparam: uart0=on
6.13 Read /overlays/vc4-kms-dsi-ili9881-7inch.dtbo bytes 3394 hnd 0x589
6.54 MESS:00:00:06.854456:0: Loaded overlay 'vc4-kms-dsi-ili9881-7inch'
6.59 Read /cmdline.txt bytes 44 hnd 0x10a
7.88 BMD "armstub8-2712.bin" not found
7.89 fs_open: 'armstub8-2712.bin'
7.93 Loading 'kernel_2712.img' to 0x00000000 offset 0x200000
7.04 Read kernel_2712.img bytes 587256 hnd 0x10c
7.06 XHCI-STOP
7.08 xHC0 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
7.14 USBSTS 0
7.17 XHCI-STOP
7.17 xHC1 ver: 272 HCS: 03000440 140000f1 07ff000a HCC: 0240fe6d
7.23 USBSTS 18
7.46 PCI1 reset
7.56 PCI2 reset
7.66 set_reboot_order 0
7.66 set_reboot_arg1 0
7.68 USB-OTG disconnect
7.10 MESS:00:00:07.310151:0: Starting OS 7310 ms
7.15 MESS:00:00:07.315677:0: 00000040: -> 00000480
7.17 MESS:00:00:07.317527:0: 00000030: -> 00100080
7.22 MESS:00:00:07.322239:0: 00000034: -> 00100080
7.26 MESS:00:00:07.326952:0: 00000038: -> 00100080
7.31 MESS:00:00:07.331666:0: 0000003c: -> 00100080
NOTICE: BL31: v2.6(release):v2.6-240-gfc45bc492
NOTICE: BL31: Built : 12:55:13, Dec 4 2024
U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000)
USB boot
No response
NVMe boot
No response
Network (TFTP boot)
No response
Unless you really need to write your own provisioning tool (which is not recommended, the bootrom signing process is quite complex) please use the secure-boot-provisioner.
https://github.com/raspberrypi/rpi-sb-provisioner
"Run boot.img with config.txt that contains program_pubkey=1"
That will do nothing. The key is only read from config.txt in secure-boot-recovery5 when config.txt is read over rpiboot
https://github.com/raspberrypi/usbboot/tree/master/secure-boot-recovery5
Please edit the config.txt file in secure-boot-recovery5, run ../tools/update-pieeprom.sh -f -k "${KEY_FILE}" and capture the UART output of the Pi5 whilst rpiboot is running. It seems to work for us with secure-boot-provisioner which wraps these tools.
N.B I don't recommend attempting to use U-boot with secure-boot unless you have already designed how u-boot will verify kernel and all of its dependencies against the hardware root of trust.
Unless you really need to write your own provisioning tool (which is not recommended, the bootrom signing process is quite complex) please use the secure-boot-provisioner. https://github.com/raspberrypi/rpi-sb-provisioner
"Run boot.img with config.txt that contains program_pubkey=1"
That will do nothing. The key is only read from
config.txtinsecure-boot-recovery5whenconfig.txtis read overrpiboothttps://github.com/raspberrypi/usbboot/tree/master/secure-boot-recovery5Please edit the
config.txtfile insecure-boot-recovery5, run../tools/update-pieeprom.sh -f -k "${KEY_FILE}"and capture the UART output of the Pi5 whilst rpiboot is running. It seems to work for us withsecure-boot-provisionerwhich wraps these tools.N.B I don't recommend attempting to use U-boot with secure-boot unless you have already designed how u-boot will verify kernel and all of its dependencies against the hardware root of trust.
I have seen rpi-sb-provisioner but it seems to require an extra hardware and do an usbboot. Can't Rpi5 provision itself ? Like I said, I have one rpi5 that has secure boot enabled with the customer key written to OTP and I never used usbboot on it. It was all done like I described from the sdcard. I'd show you the boot logs from it but I bricked it while doing something unrelated... Maybe I'll make a separate issue about it. But even in its current state it will only run the counter signed recovery.bin (it will flash green led on it and renmate it to RECOVERY.000, the public unsigned recovery.bin doesn't do it). So to me it proves that this rpi5 has the secure boot written to OTP.
As for U-Boot, with my current knowledge I'd not use it indeed. I only use it to select which kernel image and which root partition to use for a A/B boot. Since then I switched to using autoboot.txt but I'm still using the old boot.img containing U-Boot.
If you think the key customer signing key is already written then start the process from scratch using rpiboot but specify the -r flag
../tools/update-pieeprom.sh -fr -k "${KEY_FILE}"
https://github.com/raspberrypi/usbboot/tree/master/secure-boot-recovery5#sign-the-eeprom-and-the-second-stage-bootloader/
If that works you should be able to sign the mass-storage-gadget64 image and prove to yourself that verified boot is enabled and then sign your custom boot.img / OS image.
The bootloader prints the hash of the key digest on the UART at power on so you can also use this to check if the key is programmed.
If you think the key customer signing key is already written then start the process from scratch using rpiboot but specify the -r flag
../tools/update-pieeprom.sh -fr -k "${KEY_FILE}"https://github.com/raspberrypi/usbboot/tree/master/secure-boot-recovery5#sign-the-eeprom-and-the-second-stage-bootloader/If that works you should be able to sign the mass-storage-gadget64 image and prove to yourself that verified boot is enabled and then sign your custom boot.img / OS image.
The bootloader prints the hash of the key digest on the UART at power on so you can also use this to check if the key is programmed.
I will try that, but in the meantime can you tell me if it's possible at all to enable secure boot on the pi itself without external hardware ?
It's not possible. External hardware is required to avoid accidental programming of OTP - if there is a path, it's a bug.
https://www.raspberrypi.com/documentation/computers/config_txt.html#secure-boot-configuration-properties also says: "The following config.txt properties are used to program the secure-boot OTP settings. These changes are irreversible and can only be programmed via RPIBOOT when flashing the bootloader EEPROM image. This ensures that secure-boot cannot be set remotely or by accidentally inserting a stale SD card image."
https://www.raspberrypi.com/documentation/computers/config_txt.html#secure-boot-configuration-properties also says: "The following config.txt properties are used to program the secure-boot OTP settings. These changes are irreversible and can only be programmed via RPIBOOT when flashing the bootloader EEPROM image. This ensures that secure-boot cannot be set remotely or by accidentally inserting a stale SD card image."
Yes I remember seeing that but then I managed to make it work anyway and I assumed this statement is wrong. I'm not sure now how I managed to do it. To give you context, I was looking for a way to enable secure boot without any external hardware, because it was not essential to us. I just wanted to enable it if it was possible and I made it work on one of my pies. Convinced I found a way to do it I used this combination (pieeprom.upd+sig+recovery.bin+boot.img+sig) on all rpi5s that we use. Months later, last night, I noticed that the customer hash in the bootrom log is still 000000.
When I first started in august a secure boot was considered beta for raspberry pi5. Is it really possible that I found a bug and programmed secure boot on the pi itself and that should not be possible ?
AFAIK the only "external hardware" necessary is a standard USB cable between a USB-A port on your PC and the Pi5's USB-C power-input port, so maybe you did use RPIBOOT but you'd forgotten doing so?
https://www.raspberrypi.com/documentation/computers/config_txt.html#program_rpiboot_gpio "On BCM2712, you can alternatively force RPIBOOT mode by holding down the power button while simultaneously connecting a USB-C power supply." (with your PC acting as the "power supply" in this case)
AFAIK the only "external hardware" necessary is a standard USB cable between a USB-A port on your PC and the Pi5's USB-C power-input port, so maybe you did use RPIBOOT but you'd forgotten doing so?
https://www.raspberrypi.com/documentation/computers/config_txt.html#program_rpiboot_gpio "On BCM2712, you can alternatively force RPIBOOT mode by holding down the power button while simultaneously connecting a USB-C power supply." (with your PC acting as the "power supply" in this case)
I guess it is possible but I don't remember ever doing that. I was looking for a way to do it on the pi itself, connecting a different computer to the pis at the factory was not an option so I was not considering that. Well anyway, if its not supported then its not supported. Whether I somehow managed to do it on an old bootrom is not relevant (though I am curious...)
May I ask, why is not possible to program from the PI ? We can program the general purpose OTP (I store a LUKS key there) on the pi, why not the secure boot key and enable bit ?
why not the secure boot key and enable bit
I guess the most obvious answer, is that if you accidentally enable secure boot with the "wrong" key, then you've effectively just turned your Pi into a large paperweight.
We discussed this again and came to the same conclusion that secure-boot should not be enabled via 'config.txt alone. The rpiboot / sb-provisioning flow wraps much of the complexity here and goes to some lengths to avoid bricking boards or losing key material.
That's a shame. I understand you wanting to prevent accidental enabling of secure boot but I think it is valid and sensible to have this as an option. I think it would be really nice to have a RPI5 fully provision itself with just the right SD card image without needing any extra hardware to connect.
Couldn't this really be added ? Let's say an extra config.txt entry, some print and a delay on the uart to give user a 60 seconds to react and turn off the pi if they don't want to proceed or something.
+1. That's a shame.
Enabling secure boot is the only part of my entire provisioning system that will require physical interaction with my Pis. And it's a hassle getting them out of their enclosure so I can access stuff.
Honestly, I find "wrapping the complexity" a very poor excuse. It is complex, and people who can't deal with the complexity shouldn't be doing this anyways. And if they do, and they mess up, they will be able to mess up anyways. This is only hurting those who know what they're doing and want convenience, while not being effective at preventing people from messing up.
