cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
723 Views
Registered: ‎09-01-2017

Zynq-7000 (7045) RSA eFUSE fails from address 0

Jump to solution

Hi All,

Hopefully someone can help explain this odd behavior I am experiencing with a Zynq 7045's secure boot functionality.  I have burned in the RSA PPK hash to eFUSE and set the XSK_EFUSEPS_ENABLE_RSA_KEY_HASH and XSK_EFUSEPS_ENABLE_RSA_AUTH settings to TRUE in the xilskey_input.h file.  I then ran the Secure Key Driver example code to burn the eFUSEs.  This seemed to be successful, I was able to readback the RSA hash and it matched the hash that was generated using the example steps in XAPP1175 using bootgen.

I then generated a signed FSBL image using the below bif file. I am booting using QSPI and used SDK's program flash utility to burn the BOOT.bin file to address 0.  After power cycle I attached with JTAG and observed the processor did not boot my FSBL. The reboot status register read out 0x0048C000 and the Multiboot register read out 0x0000C400 indicating the BootROM searched all of flash, did not find a valid image and that the image failed validation.

The odd part was that if I program the exact same FSBL binary to any other 32K offset, the image is found and boots correctly.  I tried flashing it to 0x8000, 0x10000, 0x20000, ... 0x40000.  All of these booted correctly with the reboot status reading 0x00400000 as expected and the multiboot register displaying the expected number of "retries" to get to the correct offset (ie: 0x0000C0001 for 0x8000, 0x0000C008 for 0x40000, etc).

Before I enabled RSA authentication, the board booted successfully using an FSBL programmed at address 0 and other boards we have also boot successfully using address 0.

Our eventual goal is to enable AES encryption too, when I programmed in an encrypted and signed FSBL to address 0, the device immediately entered secure lockdown. When I programmed the same binary to 0x8000 (after switching the bootmode to JTAG to reflash), it booted fine.

I am using SDK v2017.2.  I was under the impression when using secure boot with an AES eFUSE key and authentication enabled, the BootROM would not do an image header search and FSBL* had to be located at address 0.  However it appears with testing that if the first 32K doesn't contain any image bootROM will look for and successfully decrypt and boot the FSBL image at 0x8000 which I guess can be a workaround but I was wondering why the image fails to authenticate when located at address 0x0.

I tested with the FSBL programmed to address 0x0 and another offset like 0x40000 and it ran from the 0x40000 location with the reboot status register set to 0x6048C008 which I believe indicates the original image failed authentication. I also tested programming an unsigned FSBL image at different offsets and the status was 0x6048C008 in all cases.

1. Why does the exact same image fail authentication when programmed at address 0x0 but succeeds when programmed at any other 0x8000 offset?

2. For the reboot status register, everything says the error code should be the lower 16 bits and per the TRM should be 0x2nnn. Per the fsbl.h they are all 0xAnnn.  However mine always report 0xCnnn or 0xEnnn.  What do the upper 2 bits represent?

3. Is there any harm having the encrypted and signed FSBL* image start at 0x8000 instead of 0x0 for production?  I want to accomplish the Secure Fallback Flow with eFUSE described in UG821 where FSBL* is first and then have 2 more copies of the image elsewhere in flash.

Thanks!

Bryan

bif file:

//arch = zynq; split = false; format = BIN; zynq_key_store = efuse; key_part_name = xc7z045
the_ROM_image:
{
	[aeskeyfile].\keys\fsbl_efuse.nky
        [pskfile] .\keys\psk.pem
        [sskfile] .\keys\ssk.pem
	[bootloader, encryption = aes, authentication = rsa]..\..\fsbl\Release\fsbl.elf
}
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
702 Views
Registered: ‎03-19-2014

I'm assuming you are booting from QSPI, is that correct?   From UG585 section 6.3.4 notes:

2. In cases of Quad-SPI boot, if the image is authenticated, then the boot image should be placed
at a 32K offset other than 0x0 (the image should not be placed starting at 0x0 offset in
Quad-SPI).

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

3 Replies
Highlighted
Moderator
Moderator
703 Views
Registered: ‎03-19-2014

I'm assuming you are booting from QSPI, is that correct?   From UG585 section 6.3.4 notes:

2. In cases of Quad-SPI boot, if the image is authenticated, then the boot image should be placed
at a 32K offset other than 0x0 (the image should not be placed starting at 0x0 offset in
Quad-SPI).

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Highlighted
Contributor
Contributor
692 Views
Registered: ‎09-01-2017

Wow don't know how I missed that (I am using QSPI boot), thanks!

Follow up question, right now I don't have the PL eFUSE bits XSK_EFUSEPL_FORCE_USE_AES_ONLY or XSK_EFUSEPL_BBRAM_KEY_DISABLE so the BootROM will boot encrypted or unencrypted based on the image header, and I verified using my encrypted image that it boots using the AES key in eFUSE.  When I burn those 2 fuses to mandate the AES key from eFUSE, is it still okay to have the image at a 32K offset and the BootROM won't go into secure lockdown when it does not find an image at 0x0?

0 Kudos
Highlighted
Moderator
Moderator
678 Views
Registered: ‎03-19-2014

Yes, when using AES and RSA, the 32 K offset is still necessary.  The BootROM will start mulitboot,  find the first correct header, and boot from that.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos