Boot Operation

Zynq UltraScale+ Device Technical Reference Manual (UG1085)

Document ID
UG1085
Release Date
2023-12-21
Revision
2.4 English

This Figure shows the top-level hardware root of trust boot flow used to authenticate, and optionally decrypt, the FSBL.

Note:   PMUFW is optional.

The process starts by determining which PPK to use and then validating the PPK integrity. Since the public key is stored in the boot image in external memory, it be must assumed that an adversary could tamper with it. Consequently, the CSU reads the public key from external memory, calculates its cryptographic checksum using the SHA-3/384 engine, and then compares it to the value stored in eFUSEs. If they match, the integrity of the public key has been validated and the boot can continue.

The secondary public key, and its associated ID, are then read, stored in on-chip memory (OCM), and authenticated using the PPK. Once the SPK and SPK ID have been authenticated, the CSU checks the ID that was bound to the SPK in the boot image to the ID that is stored in eFUSEs. If the IDs match, the SPK is valid and the boot can continue.

The SPK is then used to verify the authenticity of the entirety of the boot image. The CSU authenticates the FSBL, and optionally the PMUFW, while in internal memory. If encrypted, the CSU also performs the decryption.

Note:   Encrypting the configuration files is optional.

 

IMPORTANT:   The CSU processes the FSBL and PMUFW as two separation partitions. Consequently, if the FSBL and PMUFW are encrypted, the AES key and IV are reused, which is a violation of the standard.   If the FSBL and PMUFW must both be encrypted, the PMUFW must be loaded by the FSBL, and not the CSU.

At this stage, control is handed over to the user and the user is responsible for maintaining the chain of trust. The remaining secure boot process is configurable by the user. An example of a hardware root of trust secure boot process is shown in This Figure.

Figure 12-10:      Hardware Root of Trust Secure Boot Example

X-Ref Target - Figure 12-10

X21037-boot-flow-1.jpg

In this example, the FSBL is responsible for securely loading Arm trusted firmware (ATF), U-Boot, and the PL bitstream, all of which can be considered individual partitions and authenticated or encrypted separately. The FSBL executing at EL3 is responsible for all of the security checks (i.e., PPK integrity check and PPK and SPK revocation checks), as well as the actual authentication or decryption of the partitions. The hardware accelerators are used by the FSBL to authenticate or decrypt each partition.

ATF is loaded into OCM and authenticated or decrypted. U-Boot is authenticated or decrypted in external memory because it is too large for internal memory. Bitstreams are always first loaded from Flash into DDR, for systems that have DDR, regardless of security settings. In DDR-less systems, the bitstream remains in the Flash for the authentication, decryption and loading steps. If the bitstream is authenticated, then the bitstream is first validated using the RSA algorithm. If authentication passes, it is then sent from its source location (DDR or Flash) to the PCAP or to the AES decryptor and then onto PCAP. As this causes the bitstream to be read twice, once for authentication and a second time for decryption/loading, additional steps using internal OCM memory as a temporary buffer are taken to ensure the bitstream is not modified between these two reads. For more details on this secure OCM method of loading bitstreams, see the “Bitstream Authentication Using External Memory” section in the Zynq UltraScale+ MPSoC Software Developer’s Guide (UG1137) [Ref 3]. If any of these partitions fail authentication or decryption, the FSBL sets the multi-boot register and initiates a soft reset. The boot process starts over with the CSU looking for a valid boot image in memory. If a valid boot image is not found, the device goes into secure lockdown and requires a POR to exit.

To complete the secure boot process, Linux and the software to be executed on the RPU (RPU SW) must be securely loaded by U-Boot. Linux and the RPU SW might be part of the boot.bin or they might be a single partition image that is resident in a different physical memory. In either case, U-Boot does not perform the authentication or decryption but rather calls the XilSecure library, which was securely loaded as part of the PMUFW. The XilSecure library executes out of internal PMU RAM, performs all of the security checks (i.e., PPK integrity check and PPK and SPK revocation checks), and uses the CSU accelerators to do the authentication or decryption. In the event of an authentication or decryption failure, the XilSecure library passes the failure status to U-Boot.