You can have the UEFI firmware verify signatures, but there’s no way to make the Pi verify a signature on the UEFI firmware. The chain of trust is incomplete on this platform and there’s no way to fix it. A malicious person with write access to the boot partition could replace the UEFI firmware with a backdoored version, which would not be possible on a platform with UEFI Secure Boot built in.
Yes, I think the only way to make this even vaguely secure would be to use some kind of write-once / read-only storage for the boot sector.
The new SD card spec (9.0, introduced May 2022) includes provision for a write-only boot sector: https://www.sdcard.org/developers/boot-and-new-security-features/replay-protected-memory-block/ protected by a key you write to the device so if you can find an SD card that implements this part of the spec & the SD card firmware is secure, you could implement UEFI secure boot on a Pi this way. A cursory search hasn’t turned up any SD cards that implement this, but there might be some out there by now?
(The hardware switch on the larger SD cards that fitted the early Pis was only ever advisory: The host OS could ignore it entirely!)
If I understand this correctly, it does not replace the RPi firmware but merely runs after it – is that correct?
The “firmware” is really the ThreadX RTOS running on the VideoCore GPU, to which the Arm core(s) are slave processors, not actually in control of the computer.
You can have the UEFI firmware verify signatures, but there’s no way to make the Pi verify a signature on the UEFI firmware. The chain of trust is incomplete on this platform and there’s no way to fix it. A malicious person with write access to the boot partition could replace the UEFI firmware with a backdoored version, which would not be possible on a platform with UEFI Secure Boot built in.
Post updated, thanks for your comment!
Yes, I think the only way to make this even vaguely secure would be to use some kind of write-once / read-only storage for the boot sector.
The new SD card spec (9.0, introduced May 2022) includes provision for a write-only boot sector: https://www.sdcard.org/developers/boot-and-new-security-features/replay-protected-memory-block/ protected by a key you write to the device so if you can find an SD card that implements this part of the spec & the SD card firmware is secure, you could implement UEFI secure boot on a Pi this way. A cursory search hasn’t turned up any SD cards that implement this, but there might be some out there by now?
(The hardware switch on the larger SD cards that fitted the early Pis was only ever advisory: The host OS could ignore it entirely!)
The Pi 4 does support secure boot via the OTP fuses, per RPi documentation.
Yeah, that seems pretty reasonable although it’s too bad that they made up their own scheme instead of implementing UEFI
I was unaware of the possibility to use UEFI on raspberry pi. That’s aweomse. Does this mean that we can run
systemd-booton rasbperry pi?Yes! However if you also want Secure Boot you need systemd v254. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033569
If I understand this correctly, it does not replace the RPi firmware but merely runs after it – is that correct?
The “firmware” is really the ThreadX RTOS running on the VideoCore GPU, to which the Arm core(s) are slave processors, not actually in control of the computer.