On Wed, 10 Sept 2025 at 09:40, Dominik 'Rathann' Mierzejewski via arm <arm@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tuesday, 09 September 2025 at 14:26, Chris Adams via arm wrote: > [...] > > I saw the U-Boot supports Secure Boot, but... does that add any security > > in the typical Fedora setup, where U-Boot is on the same storage as > > shim, grub2, and the kernel? I would think you'd only gain security > > from U-Boot's Secure Boot support if U-Boot itself was in firmware that > > can't be modified (at least easily) from Linux. > > Fedora on PineBook Pro kind of requires U-Boot to be stored in the SPI. > As for easy modification, does SecureBoot block writes to /dev/mtd0? No, Secureboot doesn't write to anywhere, it reads the next phase in the boot process, checks it's signed by the right keys and hasn't been modified. In a fully secure firmware stack, which isn't completely related to secure boot, aarch64 has a pretty well defined way with "Boot Loader Stage X assignments AKA BLX" you have the following flow: 1) In chip bootROM (BL1) oads SPL (Secondary Boot Loader) verifying the SPL using the keys stored in chip OTP 2) SPL (BL2) initialises DRAM and loads third stage firmware (BL3 inc BL31/BL32) including TF-A, TEE, quite often SCP 3) TF-A loads system firmware BL33 (U-Boot/EDK2) which often initialises display, clocks, various other HW needed in the early boot process 4) BL33 loads the OS, which in our case we use UEFI and that may implement secure boot To have a fully secure firmware stack, protected from the OS, the SPI flash like on the Pinebook Pro, shouldn't be accessible from Linux and the update process should be through something like UEFI Capsule update. The problem is that restricting access to something like an SPI bus is complex, especially on cheap SoCs where there's not a dedicated secure co-processor. UEFI Capsule updates is also a thing that U-Boot now supports and I'm looking at how I can generate capsules so we can enable people to do automated updates to firmware using fwupdmgr so people don't need to manually update FW through some pre OS cli. -- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue