On 15/09/2020 08.20, Thirupathaiah Annapureddy wrote: > > On 9/7/2020 11:15 PM, Rasmus Villemoes wrote: >> On 02/09/2020 09.58, Rasmus Villemoes wrote: >>> On 01/09/2020 22.48, Thirupathaiah Annapureddy wrote: >>>> Anti rollback protection is required when there is a need to retire >>>> previous versions of FIT images due to security flaws in them. >>>> Currently U-Boot Verified boot does not have rollback protection to >>>> protect against known security flaws. >>> >>> This is definitely something we've had on our todo-list/wishlist. But we >>> haven't had the time to sit down and work out the semantics and >>> implementation, so thanks for doing this. >> >> ... >> >>> The board callbacks would simply be given a pointer to the data part of >>> that node; that would make the versioning scheme rather flexible instead >>> of being limited to a single monotonically increasing u32 (hence also >>> the comparison logic should be in the board callbacks, instead of a >>> "get/set" interface). >> >> Oh, and another reason for having the board callbacks being responsible >> for the Yay/Nay verdict is that that makes it possible to hook up a gpio >> that can be used to say "ignore rollback version check" - immensely >> useful during development, and might also come in handy for the end >> products. > This is not a good idea from security point of view as that would lead > to physical present attacks.
That's why I said "might". For some products physical presence is not really a relevant attack scenario (e.g. stuff that sits in an offshore windmill), but giving a service technician the possibility of overriding a rollback check can be quite valuable. But yes, in the majority of cases I'd expect such a feature to be disabled on the final product (say, by burning some e-fuse, hardwiring the gpio or whatnot). That doesn't diminish the usefulness of having it during development. Rasmus