Hi Fabian, Firstly, please can you drop your signature as it is not correct for a public mailing list.
On Tue, 14 Jan 2025 at 08:12, Koch, Fabian <[email protected]> wrote: > > Hey Simon, > > Thanks for getting back to me. > > > So long as you put your image in a configuration, it can be verified. > > The question is whether you can load it. > > Yes. Meanwhile I got far enough to have a signed FIT image, a u-boot.img > which contains the pub-key in a dtb and the means to load it all using > "imxtract" which also does the signature verification. > > So my usecase might just work without any modifications to u-boot sources. > > I only need to confirm whether this can be secure enough against attacks. If you are just using a signed image, then there is no protection against a mix-and-match attack. Are you using a signed configuration? The best approach is to use a signed configuration and then just a hash for each image. > > bootm assumes it is booting an OS. It does not support IH_TYPE_FIRMWARE as > > a type. > I currently use "standalone" in the FIT source > > > You could write a new command to handle that, perhaps. > I wanted to stay as close as possible to vanilla u-boot (or at least vanilla > TI-SDK u-boot) in order to not have to do as much work when upgrading later > on. OK. Patches are welcome, though. > > > SPL does support loading firmware, but you are running U-Boot proper so > > that isn't very useful. > Honestly, we could probably ditch u-boot proper for our usecase, but again > staying very close to the TI SDK, (which instead finally loads a Linux kernel > of course) we have been going this road so far. > Might be worth checking if we can just use SPL only, also saving on boot time. > Can you point me to how the rest (loading, verification) would look there in > SPL only? > Still a signed FIT image with "standalone" I suppose? You need to enable full FIT in SPL, but yes, it should work in a similar way. > > > For your command, you could call fit_config_verify() to verify the config, > > then fit_image_load() to load the image you want. > Both "iminfo" and "imxtract" which I currently tried run through > fit_image_check_sig() eventually, and in the .dtb I marked the image as > "required" to be verified. > Doing the negative test of loading an unsigned FIT resulted in both commands > failing and yielding a 1 as return value. > So my current plan is to do some basic bootcmd like: > > If imxtract does not fail, use "go" to jump to the entry point, Else fail the > boot > > Then I would try the "u-boot hardening" tips I found so far (like disabling > cli and console, hard-code the env, and set the delay to -2) > > If you have any more ideas on how to make this more robust, please let me > know. That seems good to me, although I'm not a security expert! > > >> [long signature with legalese] > > [can you please drop this as it is not correct for a public mailing > > list?] > > It is auto-inserted by (I suspect) the company MTA, so I don't think I can, > sorry. > I tried to send this as a plaintext mail at least, maybe that makes it a bit > more bearable. OK, please raise it with your IT people as it does create confusion and may make others reluctant to reply. > > > Kind regards and happy new year > Fabian > Informationspflicht nach Art. 13 und 14 DS-GVO: > https://www.hima.com/de/informationen-DSGVO Information obligation according > to Art. 13 and 14 DS-GVO: https://www.hima.com/en/information-GDPR > Happy New Year! [..] Regards, Simon
