Hello, wt., 16 gru 2025 o 15:59 Alexander Dahl <[email protected]> napisał(a): > Reminds me on the problems I faced when trying to implement Secure > Boot with A/B rootfs. IIRC there were two things I ended up doing: > > 1. putting the boot script in a separate volume outside of rootfs and > the A/B scheme. > > 2. use signed FIT image for the boot script instead of the old > fashioned U-Boot script, enable CONFIG_FIT_SIGNATURE, and disable (!) > CONFIG_LEGACY_IMAGE_FORMAT. > > Not sure how this plays together with standard boot, but once you > instruct U-Boot to only accept signed FIT images, that also applies > for scripts put into a FIT image. > > Greets > Alex
As you suggested, I played a bit with the boot script and fit image and indeed it's possible to include bootscript only in the fit image thus verifying it using a verified boot mechanism. It can also be loaded by the bootmeth_script. That solves part of my problem. Thanks for that suggestion. I didn't know about it before. However this is only part of the problem I'm trying to solve as I said and would be grateful for other suggestions as well, but first I will outline what I actually want to achieve. I'm trying to implement firmware and software updates for my board, but have some problems on how to approach it. As a second stage bootloader (that gets loaded by the BootROM) I'm using BL2 from TF-A. Its purpose is to load FIP (Firmware Image Package) that contains BL31 (EL3 Runtime Services), BL32 (OPTEE), BL33 (U-BOOT). Then, once the u-boot is loaded it is supposed to load the Linux kernel. Following my requirements I need to be able to update almost all components namely: FIP (thus BL31, BL32, BL33), kernel image (including bootscript) and rootfs. TF-A supports something called PSA Firmware Update that allows the selection of a FIP bank, just an ordinary A/B scheme where there are FIP-A and FIP-B copies, and the selection happens through so-called metadata. It also supports a boot counter that allows it to roll back when the boot counter reaches max boot attempt. Up to this point everything is quite straightforward. Things get more complicated when the boot process reaches the u-boot stage. As I pointed out I need to have two copies of kernel image and boot script thus I need the following: - bootscript-a - fitImage-a (kernel image) - bootscript-b - fitImage-b (kernel image) I am aware that I can embed the bootscript in the fitImage however, as I said before my fitImage is stored on the disk in the encrypted form, so the bootscript is used to decrypt the kernel image before loading. I decided to follow A/B paths for each component thus the TF-A is the source of the boot index. The information about the boot index selected by TF-A (A or B) is propagated to u-boot, so u-boot indeed has such information. The boot index can be then used to select bootscript-a/fitImage-a or bootscript-b/fitImage-b. However I'm not sure how to do this. I mean it's not technically difficult, it's rather a matter of "how it should be done correctly". What's more I want to make use of Standard Boot instead of old distro boot. Looking at the Standard Boot methods there is e.g. bootmeth_script available however I don't see how this could work in my case. This bootmeth_script just simply looks for a bootscript and if it finds it, then it loads it. As I said in my case I have bootscript-a/b, not just a single bootscript. What's even worse I cannot make separate boot partitions for boot-a and boot-b as the only partitioning scheme available on my SoC is MBR which allows you to create up to 4 partitions. I already reached this limit (boot, root-a, root-b, data), so the only reasonable solution for me would be to put the A/B artifacts in subdirectories under /boot part. To sum this up - the only sensible solution that comes to my mind is to create my own boot method that will use the TF-A provided boot index, then will scan /boot partition looking for e.g. boot-a/boot-b subdirectories (depending on the boot index) and the required bootscript (wrapped into fit Image so that it can be verified by the verified boot mechanism). However, to be honest I'm not sure if this is the right solution. Would be grateful for some suggestions. BR Patryk
