AnsweredAssumed Answered

Enabling Secure Boot on the LS1043ARDB

Question asked by Branden Sherrell on May 19, 2016
Latest reply on May 24, 2016 by Branden Sherrell

I am working to enable secure-boot on the ls1043ardb but am having a bit of trouble aggregating all the information from the reference manual and other questions to actually execute. From what I understand:


Early Boot

Very early in the boot process the SRP will restrict all I/O until all configuration fuse values are read. It is in this phase that fuses such as ITS are read. If the ITS bit it set then the device will always proceed in a secure manner, otherwise it will read the bootmode from the RCW (.e.g. sben) that has been loaded from the boot medium.



If ITS is not set, but the RCW is defined such that secure boot = 1 (.i.e. sben=1) then the core will hand over control to ISBC in some manner to indicate that the ESBC must be validated before given control. It is as this point I am having issues in the boot process.



After validation, the ISBC relinquishes control to the ESBC which further validates the kernel, and others, before continuing to boot. I found note in the reference manual (bottom, pg 1184) telling of a current bug that is preventing the use of an external bootscript, so, for now, it is built into the U-boot image. As such, I have been skipping most bootscript-related notes in the manual.





I understand that the ISBC validates the ESBC image, but how exactly does the process look? From what I understand:


  • ISBC pulls U-boot from memory at hard-coded address
  • Checks for "barker code" to ensure what was pulled is actually a CSF header
  • Validates the image based on the signature stored at the end of the image and public key available in header


Since only a hash of the private key set is fused to the SRK registers, how are the public keys and signature from in the loaded image used to validate it?


Enabling Secure Boot

From what I can tell, the procedure for enabling secure boot but not permanently blowing configuration fuses is to:


                                                                 Generating the headers/keys

  1. Generate the public/private key pair to be used to sign the images in the chain of trust
    1. ./gen_keys 1024
  2. View the hash of the public key (generated in (1)) used to sign the U-boot image
    1. This hash should be written to the SRK (see 2 below in Boot configuraiton)
  3. Generate the U-boot header
    1. ./uni_sign input_files/uni_sign/ls1043/input_uboot_nor_secure
      1. This command generates sign.out and hdr_uboot.out
      2. hdr_uboot.out is appended with the contents of the signature file (sign.out)
      3. The ls1043a supports booting a FIT kernel image. This header must also be generated, but the current problem pertains to getting to a u-boot shell.


                                                                  Boot configuration

  1. Configure the RCW such that SBEN=1 and BOOT_HO=1

    1. Various rcw*.bin files are created by default, one of which has sben set (.e.g. rcw_1500_sben.bin )
    2. Since the ITS fuse is not set, the RCW controls the secure boot mode.
    3. Boot-hold-off allows us to configure the SRK mirror registers at each POR without permanent modification
  2. On POR, write to the SRK mirror registers the hash of the private key used to sign the ESBC images and create the header
  3. Release the CPU from boot-hold-off




** What is the next step here after generating the U-boot header? Where do the headers go? Do we just flash the new RCW and U-boot (with header)?


** Some parts of the documentation seem to reference them being prepended to the respective image (pg 799 of the reference manual):


while others point to them being placed in their own partition of flash (pg 1184 of the reference manual):



Further, the reference manual shows contradicting images for the partitioning of flash. The below image (pg 99 of the reference manual) shows the kernel being placed at 0x61100000 while the above shows 0x60A00000




The second image also shows the RCW and PBI being combined to fit in the first 1M of flash, while the first image has the RCW consuming only the first 128 KB of flash with no mention of the PBI.


Other things I have found in my research that are not explicitly spelled out

I found in this question that the configuration file for CST must be modified to build for the ARM architecture rather than PowerPC (default).


I have also found references in this community that you must define CONFIG_SECURE_BOOT in U-boot as well. Is this a requirement?


In summary:

  • Where do the CSF headers go that we generate using the CST utilities?
  • If I am incorrect above in my summary, how can one evaluate secure boot without permanently modifying the SRK registers with the key hashes? What steps have I missed?
  • Which of the above memory maps is correct for the ls1043ardb?
  • Are the required PBI commands implicit in the generated RCW or is this an additional step? If so, where can I find information on this?