U-Boot v2018.07 released …with Spectre work-arounds

Tom Rini announced the latest release of U-Boot, on the u-boot mailing list:

[…]On the ARM side of things, we have the framework in, and in some cases, it is now enabled, what portion of the “Spectre” work-arounds. Since dealing with the issues entirely is a system-level problem and not just “whack some bits once and you’re good” I want to stress that to deal with the issue entirely you’re going to need more than just these changes enabled.[…]

[IMO, the U-Boot project has terse release announcements; to really understand what is new in U-Boot, you have to diff the sources and track all the current patches and issues on the mailing list, and the list is high-traffic and one of the main posters does not have an email client that properly supports threading…]

More info:

PS: Most recent set of U-Boot release stats:



CVE-2018-1000205: U-Boot, Verified Boot input validation

Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/

and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/

There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:

U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.





bootloader_instrumentation_suite: [U-Boot] Bootloader research tools (very much a work in progress)


This test suite helps you keep track of different versions of
u-boot/build tools, static analysis of that build’s binaries, and
runtime trace results of running that binary on a given hardware
configuration. For each u-boot/build configuration it keeps a database
of information it statically gathered for each boot stage, boot stage
images/ELF files, a prepared SD card image, and test results of
runtime trace analyses. If it detects changes in the u-boot source or
build tools it will create a new set of test result directories with a
new sdcard image and static analysis results.

REcon U-Boot talk, slides uploaded [temporarily]



Teddy Reed on U-Boot’s Verified Boot

Teddy Reed, author of UEFI Firmware Parser, among other things, has some U-Boot Verified Boot issues:

Verified boot production uses question

Hi all, question, is anyone using the U-Boot verified-boot in production? I am using configuration verification for several OpenCompute/OpenBMC boards. After a deep-dive review I found some edge cases that in rare circumstances could lead to a signature check bypass. I think this is low-risk at best since the scenario requires special hardware behavior to exist. Our board were susceptible in the general sense, but we had implemented some additional sanity checks on the FIT structures that
prevented this. There are some proposed changes that attempt to mitigate this [1], [2], [3]. Any one of these changes mitigates the bypass scenario. If you don’t mind reaching out to me I can share the exact situation/details.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
[2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html
[3] https://lists.denx.de/pipermail/u-boot/2018-June/330599.html



Android bootloader flow documentation published

Alex Deymo notes that the Android project has more documentation on their boot process, and posted about it on the U-Boot mailing list:

“Just an FYI, earlier this month the team spent some time polishing and publishing in source.android.com documentation about the flows the bootloader goes through in Android, specially true for stock Android like in Pixels phones or other devices based of recent AOSP versions. This documentation includes the interaction between userspace and the bootloader such as the properties userspace expects when booting A/B devices, the whole A/B flow, the bootloader message in the misc partition (BCB), how they interact with the “recovery mode” in Android and much more.