On Tuesday, January 30, 2024 at 7:43:10 AM UTC+1 Jan Kiszka wrote:
On 30.01.24 02:42, Pavel Löbl wrote: > Hi, > > I'm considering using EFI boot in some upcoming ARM based embedded > system deployment. As it seems it's the future on ARM now. What I miss a > bit is to get the whole update mechanism picture, as EFI Boot Guard is > only one piece in the chain. So I would appreciate to hear some real > world experiences. > > What we usually did in the past was the usual full A/B scheme, starting > from the BL2/SPL. So two hardware boot partitions (eMMC) for firmware, > two user boot partitions with FIT images and two root filesystems. Nice > property of this is, there is only one place which says what slot you > boot from. And that's the EXT_CSD register in eMMC which tells the ROM > code which slot we are booting to. So after the update we simply flip > this bit and everything gets loaded from the other slots. > > In EFI world I would probably used capsule update for firmware, which > can be still backed-up by hardware partitions in eMMC for redundancy. > But how to update the bootloader (EFI Boot Guard). Just by copying the > binary to ESP and calling rename()? Or rely on some EFI variables and > firmware to load the correct bootloader? > Updating EBG itself robustly indeed requires support by the EFI firmware to switch the boot paths. The renaming approach is what we currently do in isar-cip-core [1], Quirin just added it, but that is not perfect. This might be improvable by using BootNext, relying on EFI variables and their robustness - something we didn't want to do yet for the more common and frequent update of the OS, one reason for EBG to exist. I'm not even sure right now how well (and robustly) BootNext already works with the generally preferred UEFI provider on ARM, ie. U-Boot. Yes. It seems rename on FAT should be fairly atomic. So this might be a valid option. > That would mean we have active boot slot information stored at three > places. MMC register for firmware, EFI variable for bootloader slot and > bootloader configuration files for UKI. This would not be a real issue > if boot protocol between all these stages would be stable for whole > product life-cycle. But in case there will be some changes needed, we > can get in trouble if system crashes during update. We could potentially > get some "slot mixing" next boot as we are not able to update all active > slots atomically. Well, selecting firmware slots should not affect the firmware's selection of OS slots, in theory. EFI variables should be stored in a central place and should not be touched by firmware updates. And EBG also does that (via the BGENV partitions). In turn, you don't want to touch the firmware every time you only update something of the OS. That's also why something like EBG should be there to decouple things. If things would be stable and truly decoupled then yes. But if there are some changes coming in the future, then you need to track versions, and decide whether you need to flash also the lower stages of the boot chain. Especially if downgrades also need to be supported it can get quite tricky sometimes. So updating everything every time and having the switch in one place was an easy way out of this. Also not sure what is the common practice with device trees. I guess in ideal EFI setup DT would be provided by the firmware. Maybe that would work if you are using the mainline bindings all the time. As that should be fairly stable. But mainlining takes some time usually, so if things are not so ideal you rather place the DT inside UKI and then rely on that EFI fixup protocol if runtime changes are needed? But this also introduces some coupling. In case there are some rough binding changes the firmware might not be able to fixup provided DT I guess. So in practice I probably could boot "any distribution" if either that distro is using mainline kernel and my firmware provides mainline DT, or distro is providing the DT for my board and installed firmware version is able to fix it up. Pavel -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/e6fd1c00-3764-461b-8066-af2a5ee22021n%40googlegroups.com.
