Arm Trusted Firmware - 2020.2 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)

Document ID
Release Date
2020.2 English

The Zynq UltraScale+ MPSoC incorporates the standard execution model advocated for Armv8 cores. This model runs the normal operating system at a less privileged state, requiring it to request access to security-sensitive hardware or registers using a proxy software called a secure monitor. The specific secure monitor provided by Xilinx for the Zynq UltraScale+ MPSoC device is a part of Linaro Arm Trusted Firmware (ATF). Xilinx neither requires nor provides a Trusted OS However, the ATF provided by Xilinx does include hooks that allow customers to add their own Trusted OS and Trusted applications in order to implement a Trusted Execution Environment. ATF is the secure monitor that provides switching between the secure and the non-secure world. See this whitepaper for more information.

The primary purpose of ATF is to ensure that the system modules (drivers, applications) do not have access to a resource unless absolutely necessary. For example, Linux should be prevented from accessing the region where the public key is stored in the SoC. Likewise, the driver for a crypto block does not need to know the current session key; the session key could be programmed by the key negotiation algorithm and stored in a secure location within the crypto block.

Another usage of ATF is to prevent any user space application from directly accessing the hardware cryptographic engine. Instead, a user space application can make a call to the kernel where the data to be processed is copied to kernel space. Afterwards, the driver will copy the data from the kernel's virtual memory to physical address. Later, the driver will make a call to ATF and then to the PMU/CSU to perform cryptographic operations on the physical address.

PSCI is the interface from non-secure software to firmware implementing power management use-cases (for example, secondary CPU boot, hotplug, and idle). It might be necessary for supervisory systems running at exception levels to perform actions, such as restoring context and switches to the power state of core. Non-secure software can access ATF runtime services using the Arm secure monitor call (SMC) instruction.

In the Arm architecture, synchronous control transfers between the non-secure state to a secure state through SMC exceptions, which are generated by the SMC instruction, are handled by the secure monitor. The operation of the secure monitor is determined by the parameters passed in through registers.

Two types of calls are defined:

  • Fast calls to execute atomic secure operations
  • Standard calls to start preemptive secure operations

Two calling conventions for the SMC instruction defines two function identifiers for the SMC instruction define two calling conventions:

A 32-bit interface that either 32-bit or 64-bit client code can use. SMC32 passes up to six 32-bit arguments.
A 64-bit interface used only by 64-bit client code that passes up to six 64-bit arguments.

You define the SMC function identifiers based upon the calling convention. When you define the SMC function identifier, you pass that identifier into every SMC call in register R0 or W0, which determines the following:

  • Call type
  • Calling convention
  • Secure function to invoke

ATF implements a framework for configuring and managing interrupts generated in either security state. It implements a subset of the trusted board boot requirements (TBBR) and the platform design document (PDD) for Arm reference platforms.

The cold boot path is where the TBBR sequence starts when the platform is powered on, and runs up to the stage where it hands-off control to firmware running in the non-secure world in DRAM. The cold boot path starts when you physically turn on the platform.

  • You chose one of the CPUs released from reset as the primary CPU, and the remaining CPUs are considered secondary CPUs.
  • The primary CPU is chosen through platform-specific means. The cold boot path is mainly executed by the primary CPU, other than essential CPU initialization executed by all CPUs.
  • The secondary CPUs are kept in a safe platform-specific state until the primary CPU has performed enough initialization to boot them.

For a warm boot, the CPU jumps to a platform-specific address in the same processor mode as it was when released from reset.