Enabling Secure Boot on the LS1043ARDB

[brandensherrell]

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.

ISBC

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.

ESBC

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.

------------------------------------------

Validation

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?

[bpe]

>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?

>

[Platon] Fuses store a hash of the _public_ key, not the private key.

The private key is used only in signature creation, not signature

validation. SRK hash value protects the public key stored in CSF

from being modified by an attacker. Refer to LS1043RM, Sections 34.5.2 and

3.6 for  details. 

An explanation of RSA cryptosystem, including methods of signing documents/files and

subsequent signature verification, can be found here:

RSA (cryptosystem) - Wikipedia, the free encyclopedia

>** 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)?

>

[Platon] All images, including CSFs, are programmed into the Flash at

the specified addresses.

>** Some parts of the documentation seem to reference them being

>prepended to the respective image (pg 799 of the reference manual):

>

[Platon] Headers and images they refer do not need to be adjacent.

CSF headers include pointers to the images they belong to.

>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

>

[Platon] There is no contradiction. Flash maps for non-secure and secure

boot are different. If you are working with secure boot, use the map

specified in the Secure Boot ENablement chapter.

>I have also found references in this community that you must defined

>CONFIG_SECURE_BOOT in U-boot as well. Is this a requirement?

>

[Platon] Yes. Make ls1043ardb_nor_SECURE_BOOT_defconfig or add

ls1043ardb_nor_SECURE_BOOT to your UBOOT_MACHINES. See your

SDK Manual, Section 2.2.1 for  details. This will build u-Boot with

all necessary configuration macro definitions for secure boot.

>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?

>

[Platon] There is no way to do secure boot with no SRK and OTPMK programmed.

Note that you can't program fuse mirror registers with PBI because

they are blocked in secure boot mode, see LS1043ARM, Section 27.4.2.1

>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?

>

[Platon] See LS1043ARM, Section 31.4.13. Unpack Yocto package called

rcw and inspect *sben*.rcw files to see what is added for secure boot.

Have a great day,
Platon

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[brandensherrell]

Any thoughts on these final questions?

[brandensherrell]

What a great answer. Thank you so much for taking the time to pick out all the questions I had.

However, you mention there is not a way to test secure boot without burning the SRKH fuses. Is there not a way to do this without making the change permanent? Writing to the fuses is fine. I just do not want to write to the fuses in such a way as to make it permanent (i.e. making our choice of key permanent).

The manual alludes to a method of doing this by writing to the SRKH shadow registers at boot time (pg 839, section 35.9.3.5). There is an additional step to transfer the mirror register values to the SRKH register, but I was under the impression that without doing this final step then the values written to the mirror registers would suffice for secure boot testing.

How we can test secure boot by following the directions on page 8 of this​ document when we cannot access the SFP registers during secure boot (i.e. per 27.4.2.1)? According to section 31.7.3 the values of the mirror registers are 0x0 at reset unless fused, so what benefit is being able to write to these registers if we cannot actually use the values to boot in a secure way (since SBEN must be 0 to have access write access to mirror registers on boot anyway).