Secure Boot Sequence for Xilinx Zynq® UltraScale+™ MPSoC Products

Photo of Jorge Ramirez Ortiz

Posted on Jul 28, 2021 by Jorge Ramirez Ortiz

3 min read

Lmp release v83 includes support for secure boot authentication on the Xilinx Zynq® UltraScale+™ MPSoC family of products.

Introduction

The different Zynq UltraScale+ MPSoC strategies to enable Secure Boot are extensively documented on the Xilinx website on a number of application notes covering most if not all the posible use cases with examples; having said that, we found that using the Technical Reference Manual chapter 11 (Boot and Configuration Introduction) and chapter 12 (Device and Data Security and Secure Boot) together with the bootgen documentation did provide us with the context we required.

We strongly advice you to at least browse those documents.

The Configuration Security Unit (CSU) is the main functional block that implements the hardware interfaces that will provide the guarantees required to boot a secure system.

When enabled by the bootable image, it will enforce the Hardware Root of Trust, validate the integrity of the keys, perform public key revocation and handle the authentication and decryption of the bootable image.

NOTE: The CSU ROM performs all security operations: PPK integrity check, PPK/SPK Revocation, PUF Usage and Key Rolling

The Foundries.io implementation

For system coherency with the other platforms that we support at Foundries.io, we opted for replacing Xilinx's FSBL with U-boot's SPL.

There is no confidential code in the PMU firmware or in the SPL which means that encrypting this partition would not only serve no real purpose but would penalize the plaform with longer boot up times due to the required decryption; for that reason we configured the hardware root of trust to only authenticate the bootable image therefore having a minimal impact on the overall boot time.

In this configuration, SPL would be autenticated by the CSU (RSA-4096) using the PPK stored in the eFUSEs; and SPL would then read, authenticate (RSA-2048) and boot the other components from the FIT image stored in persistent storage.

The FIT image contains the following signed binaries

  • the programable logic bitstream
  • arm trusted firmware
  • u-boot
  • u-boot FDT
  • OP-TEE

Boot Sequence

On boot, the SPL configures the PMU using the pmu_cfg_obj.c and sets up the DDR and other platform bits and pieces via the psu_init_gpl.c (which is external to the U-boot tree and platform specific). There is a good description on this post from Luca Ceresoli.

Boot-image Generation

Building the ZynqMP bootable image from the U-Boot repository uses the mkimage tool to generate the image layout; mkimage also implements some basic support for the Boot Image Format file (BIF): using this BIF file the user can describe the input files to the boot image along with optional attributes for addressing, encryption, authentication or checksums. However support for these secure boot options are not present at this time.

The Xilinx's bootgen tool implements the same functionality while actually providing precisely those configuration options. And the good news is that its source code has since recently been made public. Because of this, instead of extending the mkimage BIF support, we chose to extend bootgen to enable binary images; this gave us as a way of populating the boot image bootheader with the necessary attributes and certificates for bootloader hardware authentication. Notice that the current bootgen documentation does not yet cover the support for binary bootloaders which we contributed since it is under review.

For in-depth details on the steps required to enable authentication please consult the bootgen documentation.

Learn more about how to provision an LmP supported ZynqMP Device for secure boot authentication.

Related posts