From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thirupathaiah Annapureddy Date: Mon, 14 Sep 2020 23:20:54 -0700 Subject: [RFC PATCH 0/1] Anti rollback protection for FIT Images In-Reply-To: <5c749508-d9e9-4ef4-37ef-8aa153bc296a@prevas.dk> References: <6c7e9841-6168-65ec-f506-32897cd6be1c@prevas.dk> <5c749508-d9e9-4ef4-37ef-8aa153bc296a@prevas.dk> Message-ID: <0f8b8caa-97ec-e901-ff6b-6c95e57709a1@linux.microsoft.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. > > Rasmus >