cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
msm
Visitor
Visitor
1,562 Views
Registered: ‎08-05-2019

FSBL to check integrity of Uboot

Jump to solution

I notice the default FSBL only checks the header checksum of Ubot instead of a CRC of the full Uboot image. I can see this increase boot time which is always apriciated but it has risks when you do a field upgrade of Uboot.I am interseted in the experiences of this community:

  1. Is boot time indeed the reason to do it this way?
  2. Is there a proposed way to update Uboot?
  3. If you did add a CRC check to the image what are the experiences with this

What I am thinking right now is to update the Uboot image, verify it in flash and only if this is correct write the header CRC. This way my assumption is that the header CRC check will fail if the update process is interrupted somewhere.

 

Feedback appriciated!

 

0 Kudos
1 Solution

Accepted Solutions
denist
Xilinx Employee
Xilinx Employee
1,244 Views
Registered: ‎10-11-2011

Yes, if you don't care about security an all-zero key would do it.

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

View solution in original post

16 Replies
msm
Visitor
Visitor
1,479 Views
Registered: ‎08-05-2019

We alreaddy decided to add a CRC32 check to the full image FSBL tries to load which should detect nearly any image corruption you can think of.

The same problem exists of course with FSBL. If the header is okay but the image is corrupt due to an inintended erarse of the updatable FSBL. What will happen, does the watchdog detect this problem, even if the first FSBL statement is incorrect or is there another way to avoid this failure-mode?

0 Kudos
msm
Visitor
Visitor
1,435 Views
Registered: ‎08-05-2019
We found for Uboot this is already supported using a MD5 checksum which indeed solves the problem too.
See: https://forums.xilinx.com/t5/Processor-System-Design/How-to-enable-FSBL-checksum/m-p/726902
This does an MD5 checksum for the partition the FSBL starts loading so indeed Uboot in our case.
Can we do something similar in the stage0 bootloader to check the integrity of the FSBL?
0 Kudos
denist
Xilinx Employee
Xilinx Employee
1,373 Views
Registered: ‎10-11-2011

Is this zynq-7000 or MPSoC?

For MPSoC you can use "sha3" to check the integrity of the FSBL.

For zynq-7000 you have to use the RSA (which requires eFUSE programming)

NOTE: MD5 checksum operation for Zynq®-7000 SoC devices. In these devices, checksum operations are not supported for bootloaders.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
msm
Visitor
Visitor
1,348 Views
Registered: ‎08-05-2019

@denistThank you for the answer. This is Zynq-7000 so I will look into the RSA with eFuse option although I am not too happy with the extra manufacturing complexity. Our design has a secure element to support encrypted firmware so it is not needed for security.

Regarding your remark for the MD5 check does this also count for UBoot if loaded by the FSBL for the Zynq-7000? If yes is it possible to extend the FSBL and add this check ourselves?

Thanks,

Marc

0 Kudos
denist
Xilinx Employee
Xilinx Employee
1,323 Views
Registered: ‎10-11-2011

u-boot partition will be check for MD5 by the FSBL.

FSBL should be checked by bootROM and that's not supported.

You can modify the FSBL and check on itself as first step (for example).

If you are ok with it, then you can try that. Be sure you run the checksum on "unchangeable" section of the FSBL.

DATA section for example will change and you shouldn't check those.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
denist
Xilinx Employee
Xilinx Employee
1,319 Views
Registered: ‎10-11-2011

NOTE: If you are encrypting the FSBL, you have integrity as well in there.

Encryption in zynq-7000 includes an HMAC that check integrity. If the encrypted FSBL is loaded, you are 100% sure that it's integer. 

Would that help?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
msm
Visitor
Visitor
1,265 Views
Registered: ‎08-05-2019

I thought of this too. Would it be possible to use this with just the default settings in Efuse, so only enable the encryption status with source eFuse  in the FSBL bootloader but no actual programming in eFuse. This to avoid impact on manufacturing?

0 Kudos
denist
Xilinx Employee
Xilinx Employee
1,245 Views
Registered: ‎10-11-2011

Yes, if you don't care about security an all-zero key would do it.

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

View solution in original post

msm
Visitor
Visitor
1,181 Views
Registered: ‎08-05-2019
Thanks for the support we will try this!
0 Kudos
msm
Visitor
Visitor
1,128 Views
Registered: ‎08-05-2019

We can confirm that using secure boot with an all zero key does work and detects corrupted FSBL images.
Thanks for your help!

0 Kudos
msm
Visitor
Visitor
979 Views
Registered: ‎08-05-2019

Hi @denist 

We have implemented this and it works. However if we flip a bit in the image it does not trigger the fall back mechanism of the stage-0 boot loader. Are we missing something?

Marc

0 Kudos
denist
Xilinx Employee
Xilinx Employee
961 Views
Registered: ‎10-11-2011

Is the key still all zeros? the fallback won't work with a non-zero key.

Maybe you can decode the error over INIT_B and see what it is.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
msm
Visitor
Visitor
953 Views
Registered: ‎08-05-2019

Yes this is indeed with a full zero key, would it be different if we change to a non-zero key?

Can you explain what you mean with "can decode the error over INIT_B and see what it is"  this is not clear to me.

 

0 Kudos
denist
Xilinx Employee
Xilinx Employee
906 Views
Registered: ‎10-11-2011

Take a look at UG821 (v12.0) Secure Fallback with eFUSE

In the secure boot scenario, with the AES key stored in eFUSE, the Multiboot scenario must be handled by the user (without going through a soft reset).

 

The above is true with a non-zero key.

For INIT_B error code look at UG585 (v1.12.2) 6.3.12 BootROM Error Codes.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
msm
Visitor
Visitor
886 Views
Registered: ‎08-05-2019

@denist Thank you for your answer. I see how we can detect the error via the bootROM error codes. Unfortunately this does not help a lot since we have no processor to act on this.

From the multi-boot flow chart I see with RSA enabled it should go into multiboot:

 

So I guess we have no other option than program a key and enable RSA right?
This means we can not use the all zero key which we do now. (still confused by your reply this counts for a non-zero key)

0 Kudos
denist
Xilinx Employee
Xilinx Employee
863 Views
Registered: ‎10-11-2011

I just wanted to know the error code to try to understand why this is failing.

My understanding is that the fallback should work with a all-zero AES key stored in eFUSE. 

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