[RFC PATCH 0/1] Anti rollback protection for FIT Images

[Rasmus Villemoes]

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