Tag: TI

TI on embedded SoC security

~ hucktech ~ Leave a comment

Where to Start with Embedded Processor Security
July 17th, 2017
By Amrit Mundra, Texas Instruments
The world runs on data, and every bit or byte is a potential target for attack. At the same time, both software and hardware systems are becoming much more complex, connected, and interdependent. And with complexity comes vulnerabilities. The billions or trillions of lines of code and interrelated hardware modules, subsystems, and partitions—all crammed on tiny slices of silicon—are a hacker’s delight.[…]

Figure 1: Security pyramid

 

 

http://eecatalog.com/chipdesign/2017/07/17/where-to-start-with-embedded-processor-security/

U-Boot: Secure Boot by Authenticating/Decrypting SPL FIT blobs

~ hucktech ~ Leave a comment

Andreas Dannenberg of TI submitted a patch to the U-Boot list, with an update to an earlier Secure Boot patch. Here’s the intro comment from the patch:

This patch series is derived from an earlier RFC [1] with (most of the) feedback implemented that was provided by Simon, Tom, and Lokesh (see change log at the end). There are still some loose ends namely affecting the make process (see discussion here [2], maybe Yamada-san has some inputs?) as well as the conversion of the “weak” post-process function call to a Kconfig option. We did experiment with a few options regarding the Kconfig conversion but couldn’t really settle on a good way. Simon or Tom- if you could provide a tiny bit of additional direction here we will be happy to re-visit this and change the current implementation.

Here’s again the high-level summary of what we are trying to achieve:

A method is introduced 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.

I also just re-rested the patch series on actual AM437x HS, DRA7 HS, DRA72 HS, and AM57 HS device variants by building and running SPL/U-Boot. I’ve also build-tested the corresponding non-HS device variant configurations to make sure nothing is broken there.

Changes RFC->PATCH:
– Update of README.ti-secure
– Unification of some of the secure ROM API call stuff between AM43xx and
  OMAP5-based platforms by moving those into common files
– Replacement of puts() with printf()
– Minor build simplification/cleanup
– Addition of “Reviewed-by:” comments for files that were pretty much carried
  over from the RFC as-is
– Addition of AM437x HS device build support (was missing in RFC)
– Removal of some redundant conditional compile directives
– Rebased on upstream U-Boot commit “Prepare v2016.07-rc2”

Regards,
Andreas Dannenberg

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg216299.html
[2] https://www.mail-archive.com/u-boot@lists.denx.de/msg216298.html

Andreas Dannenberg (4):
  arm: omap-common: add secure rom call API for secure devices
  arm: omap-common: secure ROM signature verify API
  arm: omap-common: Update to generate secure U-Boot FIT blob
  arm: omap5: add U-Boot FIT signing and SPL image post-processing

Daniel Allred (4):
  arm: cache: add missing dummy functions for when dcache disabled
  spl: fit: add support for post-processing of images
  arm: omap-common: add secure smc entry
  doc: Update info on using secure devices from TI

Madan Srinivas (1):
  arm: am4x: add U-Boot FIT signing and SPL image post-processing

See the patch email thread on the U-Boot list for more details.
http://lists.denx.de/mailman/listinfo/u-boot

TI adds RapidIO support to U-Boot

~ hucktech ~ Leave a comment

Aurelien Jacquiot of TI recently submitted a patch to U-Boot, adding support for RapidIO, initially designed to support the TI KeyStone architecture. Comments from initial patch message:

“RapidIO is a high-performance packet-switched interconnect technology that can be used for messaging or memory transfers like Ethernet or PCIe. This feature adds the RapidIO boot functionality for slave mode (i.e. U-Boot does not fetch the images, images are pushed by a peer device/board). A new ‘rio’ command group allows to initialize and perform basic RapidIO operations. In addition the ‘mem’ group command has been enhanced in order to wait a given value in memory (to be notified that images have been pushed by peer). This feature has been firstly designed for TI KeyStone architecture and patches includes the RapidIO controller device driver for KeyStone architecture but it can used by any device/architecture that has hardware RapidIO support with DirectI/O. There just to add the corresponding RapidIO controller device driver. For more information, read the doc/README.rapidio documentation.”

More Information:
http://www.rapidio.org/
http://lists.denx.de/mailman/listinfo/u-boot
http://www.ti.com/sitesearch/docs/universalsearch.tsp?searchTerm=RapidIO#