Linaro Community Projects Division announces the Trusted Firmware open project
San Jose – WEBWIRE – Tuesday, October 16, 2018
The Trusted Firmware project promises to provide an important software foundation to further security development for both Cortex-A and Cortex-M/R processors. Linaro Community Projects Division, the division of Linaro managing open source community projects with open governance, today announced that Trusted Firmware is available as a Linaro Community Projects Division open project. Trusted Firmware provides a reference implementation of Secure World software for Armv7, Armv8-A and Armv8-M architectures. It provides SoC developers and OEMs with a reference trusted code base complying with the relevant Arm specifications. This forms the foundations of a Trusted Execution Environment (TEE) on application processors, or the Secure Processing Environment (SPE) on microcontrollers.[…]
ARM has new threat model docs available for their PSA, and have announced that they’ll be releasing ARM Trusted Firmware with PSA support at the end of the month, you can give them your email address to be notified when it is released.
[…]we announced a major program to improve IoT security, called Platform Security Architecture (PSA). PSA is a common framework aiming to provide a holistic approach to IoT security.[…]Now available! Open Source Trusted Firmware-M. Arm wants to make security simpler and more cost effective, by making high quality reference code and documents accessible – as security becomes more complex, all developers need access to these resources. We have released the first open source reference implementation firmware that conforms to the PSA specification, Trusted Firmware-M, at the end of March 2018.[…] Download now: Threat Models and Security Analyses documentation: The TMSA is a starting point for assessing the security risk facing a selection of connected devices. From this research, the right level of security can be determined, and then functional requirements established to mitigate the threats.
the second blog post is out, covering Spectre/Meltdown impact on: UEFI, ARM Trusted Firmware, U-Boot, OP-TEE, and Linux kernel. Good reading!
“This is a walkthrough for flashing custom ARM Trusted Firmware, OP-TEE, and the ARM UEFI Platform code on the Hikey board. Custom means code we’ve built it on our development machine, we’re not making any changes to these reference implementations just yet.[…]”
“Amlogic S905 processor used in many Android TV boxes and ODROID-C2 development board implements ARM TrustZone security extensions to run a Trusted Execution Environment (TEE) used for DRM & other security features. However, Frédéric Basse, a security engineer, worked with others and managed to bypass secure boot in one Amlogic S905 powered Android TV box, namely Inphic i7, but any other device based on the processor would have made the same thing possible. […]”
This week Linus Walleij of Linaro posted a long blog article on U-Boot this week, with good background on U-Boot on ARM, as well as current AArch64 support, including integration with ARM Trusted Firmware (ARM TF). Excerpting the concluding paragraphs of the blog:
We now have pieced together a system that will start U-Boot from ARM Trusted Firmware and then have U-Boot load the Linux kernel and a device tree and start it. Are there problems remaining?
* One of the big outstanding issues are those where things are fragile because memory references need be hard-coded in U-Boot or ARM Trusted Firmware. For example U-Boot currently assumes that ARM TF will use 16MB of the DRAM memory. If the ARM TF change things around and use more or less memory, U-Boot needs to be reconfigured and recompiled. U-Boot on the other hand, will then pass whatever knowledge it has about the memory to the Linux kernel by augmenting the device tree. So if ARM TF could communicate the memory available to U-Boot and the OS this would be great.
* U-Boot relies on prior boot stages such as ARM Trusted Firmware to install PSCI handlers, while on ARMv7 this was usually done by augmenting U-Boot to do the same. Letting U-Boot install PSCI handlers is a bit bogus, since it is a piece of resident code left in memory after U-Boot has executed and not really “boot loader” code. U-Boot was augmented to compile these into a special memory area, copy them there and leave them around for the operating system to use later. Still there are people who might like to do this on ARMv8 U-Boot, especially those not using ARM Trusted Firmware.
* People apparently toy with the idea of booting U-Boot on bare metal, using a very small or no ROM nor ARM Trusted Firmware, letting U-Boot just execute immediately on the system. As U-Boot relies on something else to set up main memory and providing PSCI, this currently does not work. Doing this would require U-Boot to initialize memory and install PSCI handlers. It would also need to be small enough to execute from on-chip RAM.
* Chain of trust booting with signed boot levels, signed U-Boot and a signed kernel image and a signed device tree, making an example of a totally locked-down system. The Flattened Image Tree (FIT) supported by U-Boot is likely the best way forward here, but requires U-Boot to access public key infrastructure to verify images unless you want to compile the public key directly into U-Boot, which is often not a good idea.
* Fastboot – the Android boot protocol used by the Little Kernel, exists in U-Boot but has not been tested or verified. It can use USB or Ethernet alike.
* More hardware support – such as booting from the USB stick or MMC/SD card found in the Juno board. This was not covered by the experimental port.
Read the full article here: