Trusted Firmware-A - 2023.2 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)

Document ID
UG1137
Release Date
2023-11-28
Version
2023.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 level, 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 AMD for the Zynq UltraScale+ MPSoC device is a part of Linaro Trusted Firmware-A (TF-A). AMD neither requires nor provides a Trusted OS directly but provides solutions via third parties. However, the TF-A provided by AMD does include hooks that allow customers to add their own Trusted OS and Trusted applications to implement a Trusted Execution Environment. TF-A is the secure monitor that provides switching between the secure and the non-secure world. See WP516 for more information.

The primary purpose of TF-A is to ensure that the system modules (drivers, applications) are isolated from security resources. For example, Linux should be prevented from accessing the region where a private 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 TF-A 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 TF-A and then to the PMU/CSU to perform cryptographic operations on the physical address. For more information, see WP512.

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 to perform actions, such as restoring context and switches to the power state of core. Non-secure software can call TF-A 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 are handled through SMC exceptions, which are generated by the SMC instruction. These 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:

SMC32
A 32-bit interface that either 32-bit or 64-bit client code can use. SMC32 passes up to six 32-bit arguments.
SMC64
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

TF-A 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.