Andreas Dannenberg of TI has submitted a 9-part patch to the U-Boot project, adding LOTS more security to the boot process. It includes and depends on some other recent patches by Madan Srinivas, Daniel Allred, and others I think (sorry for lack of attribution).
[RFC 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
This is an RFC for a method that uses a “weak” post-process function call that’s injected into the SPL FIT loading process after each blob has been extracted (U-Boot firmware, selected DTB) which is populated with a platform specific function. In case of TI high-security (HS) device variants a ROM API call is performed (via SMC) that transparently handles authentication and optional decryption. This essentially allows authenticating (and optionally decrypting) U-Boot from SPL. The post-processing injection is implemented such to enable a more universal use of this feature by other platforms or for other purposes.
Furthermore the build process has been modified to automatically invoke a TI blob signing/encryption tool through the $TI_SECURE_DEV_PKG env variable already introduced into U-Boot. This singing/encryption step happens for each artifact that gets bundled into the final u-boot.img FIT blob.
Why do we need this for our platforms if some generic form of verified boot already exists in U-Boot? The approach proposed here provides support for decryption which is currently not available in U-Boot (and may not be easily implementable generically for example due to the need for keeping symmetric keys secure). Furthermore it allows for a consistent build as well as runtime flow no matter authentication and/or decryption is used (as opposed to using existing U-Boot verified boot for authentication and an additional TI-specific ROM API call for decryption for example). It also allows for a faster and more efficient boot process (auth and decryption can be performed in a single step by the ROM APIs also utilizing crypto HW accelerators in a completely transparent fashion). However anyone can still use the standard U-Boot verified boot scheme from U-Boot onwards if they so chose and only need authentication.
The patch series has been tested on DRA7 HS, DRA72 HS, and AM57 HS device variants. The AM43 HS support is still missing some Makefile changes but the principle in the final implementation will be similar what’s implemented for the other devices.
spl: fit: add support for post-processing of images
arm: cache: add missing dummy functions for when dcache disabled
arm: omap-common: add secure smc entry
arm: omap-common: add secure rom call API for secure devices
arm: omap5: add secure ROM signature verify API
arm: omap5: add FIT image post process function
ti: omap-common: Update to generate secure FIT
arm: am4x: add secure ROM signature verify API
arm: am4x: add FIT image post process function
[RFC 1/9] spl: fit: add support for post-processing of images
The next stage boot loader image and the selected FDT can be post-processed by board/platform/device-specific code, which can include modifying the size and altering the starting source address before copying these binary blobs to their final desitination. This might be desired to do things like strip headers or footers attached to the images before they were packeaged into the FIT, or to perform operations such as decryption or authentication.
[RFC 2/9] arm: cache: add missing dummy functions for when dcache disabled
Adds missing flush_dcache_range and invalidate_dcache_range dummy (empty) placeholder functions to the #else portion of the #ifndef CONFIG_SYS_DCACHE_OFF, where full implementations of these functions are defined.
[RFC 3/9] arm: omap-common: add secure smc entry
Adds an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible devices.
[RFC 4/9] arm: omap-common: add secure rom call API for secure devices Adds a generic C-callable API for making secure ROM calls on OMAP and OMAP-compatible devices. This API provides the important function of flushing the ROM call arguments to memory from the cache, so that the secure world will have a coherent view of those arguments. Then is simply calls the omap_smc_sec routine.
[RFC 5/9] arm: omap5: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention.
[RFC 6/9] arm: omap5: add FIT image post process function
Adds a board specific FIT image post processing function for when CONFIG_SECURE_BOOT is defined. Also update the omap common config header to enable CONFIG_SECURE_BOOT always for secure TI devices (CONFIG_TI_SECURE_DEVICE is defined).
[RFC 7/9] arm: am4x: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention. This API is common across AM3x HS and AM4x HS devices.
[RFC 8/9] arm: am4x: add FIT image post process function
Adds a board specific FIT image post processing function when u-boot is compiled for the high-secure (HS) device variant.
[RFC 9/9] ti: omap-common: Update to generate secure FIT
Adds commands so that when a secure device is in use and the SPL is built to load a FIT image (with combined u-boot binary and various DTBs), these components that get fed into the FIT are all processed to be signed/encrypted/etc. as per the operations performed by the secure-binary-image script of the TI SECDEV package.
For more information, see the full patch on the list:
http://lists.denx.de/mailman/listinfo/u-boot
Firmware Security 
You must be logged in to post a comment.