Go to file
Masahiro Yamada 11c0a4ff08 fiptool: fix add_image() and add_image_desc() implementation
The "make fip" shows the content of the generated FIP at the end of
the build.  (This is shown by "fiptool info" command.)

Prior to commit e0f083a09b ("fiptool: Prepare ground for expanding
the set of images at runtime"), the last part of the build log of
 make CROSS_COMPILE=aarch64-linux-gnu- BL33=../u-boot/u-boot.bin fip
was like follows:

 Trusted Boot Firmware BL2: offset=0xB0, size=0x4188, cmdline="--tb-fw"
 EL3 Runtime Firmware BL31: offset=0x4238, size=0x6090, cmdline="--soc-fw"
 Non-Trusted Firmware BL33: offset=0xA2C8, size=0x58B51, cmdline="--nt-fw"

With that commit, now it is displayed like follows:

 Non-Trusted Firmware BL33: offset=0xB0, size=0x58B51, cmdline="--nt-fw"
 EL3 Runtime Firmware BL31: offset=0x58C01, size=0x6090, cmdline="--soc-fw"
 Trusted Boot Firmware BL2: offset=0x5EC91, size=0x4188, cmdline="--tb-fw"

You will notice two differences:
  - the contents are displayed in BL33, BL31, BL2 order
  - the offset values are wrong

The latter is more serious, and means "fiptool info" is broken.

Another interesting change is "fiptool update" every time reverses
the image order.  For example, if you input FIP with BL2, BL31, BL33
in this order, the command will pack BL33, BL31, BL2 into FIP, in
this order.  Of course, the order of components is not a big deal
except that users will have poor impression about this.

The root cause is in the implementation of add_image(); the
image_head points to the last added image.  For example, if you call
add_image() for BL2, BL31, BL33 in this order, the resulted image
chain is:

  image_head -> BL33 -> BL31 -> BL2

Then, they are processed from the image_head in "for" loops:

  for (image = image_head; image != NULL; image = image->next) {

This means images are handled in Last-In First-Out manner.

Interestingly, "fiptool create" is still correct because
add_image_desc() also reverses the descriptor order and the command
works as before due to the double reverse.

The implementation of add_image() is efficient, but it made the
situation too complicated.

Let's make image_head point to the first added image.  This will
add_image() inefficient because every call of add_image() follows
the ->next chain to get the tail.  We can solve it by adopting a
nicer linked list structure, but I am not doing as far as that
because we handle only limited number of images anyway.

Do likewise for add_image_desc().

Fixes: e0f083a09b ("fiptool: Prepare ground for expanding the set of images at runtime")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-15 02:58:03 +09:00
bl1 Fix integer overflows in BL1 FWU code 2016-12-20 11:43:10 +00:00
bl2 Define and use no_ret macro where no return is expected 2016-12-05 14:55:35 +00:00
bl2u Define and use no_ret macro where no return is expected 2016-12-05 14:55:35 +00:00
bl31 Define and use no_ret macro where no return is expected 2016-12-05 14:55:35 +00:00
bl32 Abort preempted TSP STD SMC after PSCI CPU suspend 2016-12-23 10:46:32 +00:00
common Merge pull request #791 from jeenu-arm/asm-assert-32 2016-12-20 17:00:32 +00:00
docs Merge pull request #788 from jeenu-arm/cpuops-framework 2016-12-20 12:27:58 +00:00
drivers Merge pull request #807 from nmenon/upstream/fix-16650-rx 2017-01-13 17:18:59 +00:00
fdts Fix incorrect copyright notices 2016-12-14 14:31:32 +00:00
include Merge pull request #807 from nmenon/upstream/fix-16650-rx 2017-01-13 17:18:59 +00:00
lib Merge pull request #788 from jeenu-arm/cpuops-framework 2016-12-20 12:27:58 +00:00
make_helpers Build: add -MP option to add dummy rules to *.d files 2017-01-05 11:39:19 +09:00
plat Merge pull request #805 from Xilinx/zynqmp/addr_space_size 2017-01-10 11:12:08 +00:00
services Abort preempted TSP STD SMC after PSCI CPU suspend 2016-12-23 10:46:32 +00:00
tools fiptool: fix add_image() and add_image_desc() implementation 2017-01-15 02:58:03 +09:00
.checkpatch.conf Mandate 'Signed-off-by' line in commit messages 2016-10-24 13:44:59 +01:00
.gitignore .gitignore: ignore editor backup files 2016-10-25 01:21:01 +09:00
acknowledgements.md Add Xilinx to acknowledgements file 2016-04-06 10:44:27 -07:00
contributing.md Drop requirement for CLA in contribution.md 2016-09-27 21:52:03 +01:00
dco.txt Drop requirement for CLA in contribution.md 2016-09-27 21:52:03 +01:00
license.md Update year in copyright text to 2014 2014-01-17 10:27:53 +00:00
Makefile Build: use CPP just for pre-processing 2017-01-05 11:35:59 +09:00
readme.md readme.md: Add tested Linaro release information for FVPs 2016-11-09 13:18:36 +00:00

ARM Trusted Firmware - version 1.3

ARM Trusted Firmware provides a reference implementation of secure world software for ARMv8-A, including a [Secure Monitor] TEE-SMC executing at Exception Level 3 (EL3). It implements various ARM interface standards, such as the Power State Coordination Interface (PSCI), Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1) and SMC Calling Convention. As far as possible the code is designed for reuse or porting to other ARMv8-A model and hardware platforms.

ARM will continue development in collaboration with interested parties to provide a full reference implementation of PSCI, TBBR and Secure Monitor code to the benefit of all developers working with ARMv8-A TrustZone technology.

License

The software is provided under a BSD-3-Clause license. Contributions to this project are accepted under the same license with developer sign-off as described in the Contributing Guidelines.

This project contains code from other projects as listed below. The original license text is included in those source files.

  • The stdlib source code is derived from FreeBSD code.

  • The libfdt source code is dual licensed. It is used by this project under the terms of the BSD-2-Clause license.

This Release

This release provides a suitable starting point for productization of secure world boot and runtime firmware, executing in either the AArch32 or AArch64 execution state.

Users are encouraged to do their own security validation, including penetration testing, on any secure world code derived from ARM Trusted Firmware.

Functionality

  • Initialization of the secure world (for example, exception vectors, control registers, interrupt controller and interrupts for the platform), before transitioning into the normal world at the Exception Level and Register Width specified by the platform.

  • Library support for CPU specific reset and power down sequences. This includes support for errata workarounds.

  • Drivers for both versions 2.0 and 3.0 of the ARM Generic Interrupt Controller specifications (GICv2 and GICv3). The latter also enables GICv3 hardware systems that do not contain legacy GICv2 support.

  • Drivers to enable standard initialization of ARM System IP, for example Cache Coherent Interconnect (CCI), Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone Controller (TZC).

  • SMC (Secure Monitor Call) handling, conforming to the SMC Calling Convention using an EL3 runtime services framework.

  • PSCI library support for the Secondary CPU Boot, CPU Hotplug, CPU Idle and System Shutdown/Reset/Suspend use-cases. This library is pre-integrated with the provided AArch64 EL3 Runtime Software, and is also suitable for integration into other EL3 Runtime Software.

  • A minimal AArch32 Secure Payload to demonstrate PSCI library integration on platforms with AArch32 EL3 Runtime Software.

  • Secure Monitor library code such as world switching, EL1 context management and interrupt routing. When using the provided AArch64 EL3 Runtime Software, this must be integrated with a Secure-EL1 Payload Dispatcher (SPD) component to customize the interaction with a Secure-EL1 Payload (SP), for example a Secure OS.

  • A Test Secure-EL1 Payload and Dispatcher to demonstrate AArch64 Secure Monitor functionality and Secure-EL1 interaction with PSCI.

  • AArch64 SPDs for the OP-TEE Secure OS and [NVidia Trusted Little Kernel] NVidia TLK.

  • A Trusted Board Boot implementation, conforming to all mandatory TBBR requirements. This includes image authentication using certificates, a Firmware Update (or recovery mode) boot flow, and packaging of the various firmware images into a Firmware Image Package (FIP) to be loaded from non-volatile storage. The TBBR implementation is currently only supported in the AArch64 build.

  • Support for alternative boot flows. Some platforms have their own boot firmware and only require the AArch64 EL3 Runtime Software provided by this project. Other platforms require minimal initialization before booting into an arbitrary EL3 payload.

For a full description of functionality and implementation details, please see the Firmware Design and supporting documentation. The Change Log provides details of changes made since the last release.

Platforms

The AArch64 build of this release has been tested on variants r0, r1 and r2 of the [Juno ARM Development Platform] Juno with Linaro Release 16.06.

The AArch64 build of this release has been tested on the following ARM FVPs (64-bit host machine only, with Linaro Release 16.06):

  • Foundation_Platform (Version 10.1, Build 10.1.32)
  • FVP_Base_AEMv8A-AEMv8A (Version 7.7, Build 0.8.7701)
  • FVP_Base_Cortex-A57x4-A53x4 (Version 7.7, Build 0.8.7701)
  • FVP_Base_Cortex-A57x1-A53x1 (Version 7.7, Build 0.8.7701)
  • FVP_Base_Cortex-A57x2-A53x4 (Version 7.7, Build 0.8.7701)

The AArch32 build of this release has been tested on the following ARM FVPs (64-bit host machine only, with Linaro Release 16.06):

  • FVP_Base_AEMv8A-AEMv8A (Version 7.7, Build 0.8.7701)
  • FVP_Base_Cortex-A32x4 (Version 10.1, Build 10.1.32)

The Foundation FVP can be downloaded free of charge. The Base FVPs can be licensed from ARM: see [www.arm.com/fvp] FVP.

This release also contains the following platform support:

  • MediaTek MT6795 and MT8173 SoCs
  • NVidia T210 and T132 SoCs
  • QEMU emulator
  • RockChip RK3368 and RK3399 SoCs
  • Xilinx Zynq UltraScale + MPSoC

Still to Come

  • AArch32 TBBR support and ongoing TBBR alignment.

  • More platform support.

  • Ongoing support for new architectural features, CPUs and System IP.

  • Ongoing PSCI alignment and feature support.

  • Ongoing security hardening, optimization and quality improvements.

For a full list of detailed issues in the current code, please see the Change Log and the GitHub issue tracker.

Getting Started

Get the Trusted Firmware source code from GitHub.

See the User Guide for instructions on how to install, build and use the Trusted Firmware with the ARM FVPs.

See the Firmware Design for information on how the ARM Trusted Firmware works.

See the Porting Guide as well for information about how to use this software on another ARMv8-A platform.

See the Contributing Guidelines for information on how to contribute to this project and the Acknowledgments file for a list of contributors to the project.

Feedback and support

ARM welcomes any feedback on the Trusted Firmware. Please send feedback using the GitHub issue tracker.

ARM licensees may contact ARM directly via their partner managers.


Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved.