LS1084ARDB secure boot issue

[tzongruey]

Hi,

I have set SB_EN=1 for secure boot in the RCW file.
I try to use firmware_ls1088ardb_uboot_qspiboot_secure.img to flash NOR on my platform and try to boot up.
In the beginning, it can boot up successfully, but it will show the following error message, and can not stay in uboot to enter the command

NOTICE: ROTPK is not deployed on platform. Skipping ROTPK verification.
ERROR: Error in installing ROTPK table
ERROR: SRK hash doesn't match the fuse hash
ERROR: ROTPK FAILURE
ERROR: SECURE BOOT DEVE MODE : CONTINUING ON FAILURE. CHECK ROTPK
........
ERROR :: 400 :: Public key hash comparison failed
SEC_MON already in Non Secure state.

So I modified the return value of the abortboot function in packages/firmware/u-boot/common/autoboot.c
Then, the secure boot image can stay in uboot, enter the following md and mw commands
The input value is according to the generated OTPMK and SRKH.
After entering the following command, I tried to restart the platform
But it couldn't boot up.

=> md 0x1e90014

=> mw 0x1e80234 0xca301f1d
=> mw 0x1e80238 0xebbad2eb
=> mw 0x1e8023c 0x1afa68c5
=> mw 0x1e80240 0x956ee93c
=> mw 0x1e80244 0xcd750046
=> mw 0x1e80248 0x5c8c5792
=> mw 0x1e8024c 0xfdc12435
=> mw 0x1e80250 0x4dd802f8

=> md 0x1e90014
=> md 0x1e80024

=> mw 0x1e80020 0x2

=> mw 0x1e80254 0x244fdad5
=> mw 0x1e80258 0x1d216e05
=> mw 0x1e8025c 0xeae7dc7a
=> mw 0x1e80260 0x03cc4a25
=> mw 0x1e80264 0xd75dc191
=> mw 0x1e80268 0xfde52e47
=> mw 0x1e8026c 0xacebc955
=> mw 0x1e80270 0xba1f57b1

The current situation becomes that as long as firmware_ls1088ardb_uboot_qspiboot_secure.img is used, it can't boot up.
The only way to boot up is to flash back firmware_ls1088ardb_uboot_qspiboot.img
What should I do to boot using firmware_ls1088ardb_uboot_qspiboot_secure.img?

Thanks

[JosephAtNXP]

Hi, do you have your fuses blew?

[tzongruey]

Hi,

Did you mean the build configuration of CONFIG_FUSE_PROVISIONING in configs/build_lsdk.cfg?
I have set it as y.

Thanks

[JosephAtNXP]

Hi, two questions:

Have you followed the steps that the 6.1.1.5.2 Prepare board for Secure boot part suggests? And if so, have you checked that those writings indeed were written?

The other question is regarding to your image, could you please tell me how did you built your image?

Thanks in advance, best regards.

[tzongruey]

Hi,

I didn't follow the steps of chapter 6.1.1.5.2 Prepare board for Secure boot in LSDK21.08 completely.
The LSDK version I used was 20.04 update290520.
Therefore, I referred to the document of the LSDK 20.04 update290520 version.

I checked the steps of chapter 6.1.1.5.2 Prepare board for Secure boot in LSDK21.08
When I used uboot command(md mw) to write OTPMK and SRKH, I didn't do byte swaps for OTPMK and SRKH.
Is that causing this issue?
How could I fix it?

When I built a secure image, I only modified SB_EN in RCW to 1
The other parts are the same as when I built a non-secure image
Currently, I only can use a non-secure image to boot up.

Thanks

[JosephAtNXP]

Hi,

please take the guide up.

Enable POVD putting the corresponding jumper in order to enable SFP. After that, perform the first step to write to OTPMK and SRKH, this would be reading if the fuses are already blown, if you need to re-write those fuses, the workaround would be change your chip for another one.

If your chip has been replaced, take this guide to prepare the board. This causes the issue for sure, your image won't hash nor match, neither any software.

Nonetheless, I also wanted to see how your image was built. I meant if you used flex-builder or performed it manually, and how did you do that.

[tzongruey]

Hi,

The attached picture is the schematics of our platform.
I have put the jumper to the TA_PROG_SFP pin(connect TP649 and TP650) to enable SFP in my previous test.
If I set the CONFIG_FUSE_PROVISIONING as y in configs/build_lsdk.cfg
Is the OTPMK and SRKH will pack into firmware_ls1088ardb_qspiboot_secure.img or not?
I am confused about that.
I couldn't boot up with a secure image.
If I want to rewrite the OTPMK and SRKH, I couldn't use the console to rewrite them.
I built my image by using flex-builder.
I used flex-build -m ls1088ardb -a arm64 or flex-build -m ls1088ardb -a arm64 -s to generate the secure image.

Thanks

[JosephAtNXP]

Hi, tzongruey

Ok, here's what is happenning.

The Super Root Key Hash (SRKH) and the OTP Master Key registers are keys used by the CAAM module to hash information, those can validate images and softwares by using its information in hashing functions. For secured reasons, those are implemented as fuses inside the device, once you set a fuse to 1 or 0, those fuses will blow and never set another value.

That is why you need to connect a jumper in the RDB, to be completely sure that you are going to set those fuses [blowing register by register or all the registers with a fuse provisioning file and the file_provisioning -> y], what happened here is that you did blow your fuses and you did not do byte swapping, so the key won't match for the image. So, you should get a new device that occupies the old one with not-blown fuses and get you key typed again.

You should do byte swapping, as the last version states, and follow that guide. Also, let me check that command you used for building that image.

[tzongruey]

Hi,

I want to confirm the generation of the OTPMK and SRKH.
Are the OTPMK and SRKH will generate when using flex-builder -m ls1088ardb -a arm64 -s to build code?
Or do I need to use the command ./gen_otpmk_drbg --b 2 to generate the OTPMK and ./uni_sign --hash to generate the SRKH

In addition, I also want to confirm the byte swap of the OTPMK and the SRKH, if the generated OTPMK is as follows

OTPMK[255:0] is:
2e89c524788e777bef7abff23635627e65070e76b3aca9dab5214243d6808a11

NAME | BITS | VALUE
_________|______________|____________
OTPMKR 0 | 255-224 | 2e89c524
OTPMKR 1 | 223-192 | 788e777b
OTPMKR 2 | 191-160 | ef7abff2
OTPMKR 3 | 159-128 | 3635627e
OTPMKR 4 | 127- 96 | 65070e76
OTPMKR 5 | 95- 64 | b3aca9da
OTPMKR 6 | 63- 32 | b5214243
OTPMKR 7 | 31- 0 | d6808a11

The byte swap of the OTPMK I do is the following.
Is it correct?

=> mw 0x1e80234 0x24c5892e
=> mw 0x1e80238 0x7b778e78
=> mw 0x1e8023c 0xf2bf7aef
=> mw 0x1e80240 0x7e623536
=> mw 0x1e80244 0x760e0765
=> mw 0x1e80248 0xdaa9acb3
=> mw 0x1e8024c 0x434221b5
=> mw 0x1e80250 0x118a80d6

Similarly, if the generated SRKH is as follows.

SRK (Public Key) Hash:
b0afeac4309c3d913e2c33a59396b4c396b5e240d5b17fbb4cd088a938704fdc
SFP SRKHR0 = b0afeac4
SFP SRKHR1 = 309c3d91
SFP SRKHR2 = 3e2c33a5
SFP SRKHR3 = 9396b4c3
SFP SRKHR4 = 96b5e240
SFP SRKHR5 = d5b17fbb
SFP SRKHR6 = 4cd088a9
SFP SRKHR7 = 38704fdc

The byte swap of the SRKH I do is the following.

=> mw 0x1e80254 0xc4eaafb0
=> mw 0x1e80258 0x913d9c30
=> mw 0x1e8025c 0xa5332c3e
=> mw 0x1e80260 0xc3b49693
=> mw 0x1e80264 0x40e2b596
=> mw 0x1e80268 0xbb7fb1d5
=> mw 0x1e8026c 0xa988d04c
=> mw 0x1e80270 0xdc4f7038

Is it correct?

Thanks

[JosephAtNXP]

Yes, according to 

6.1.1.5.2.2 Byte swap for reading and writing SRKH/OTPMK

You should write to OTPMK and SRKH considering the core endianness and using u-boot, it is correct that the bytes should be swapped.

Look at the example provided for the guide, if the generated keys were given using the commands for generating them, you are swapping your bytes correctly and putting them into the correct register.

Also, the OTPMK is generated correctly, the same goes for the SRKH generation.

Anyway, could be helpful to check what the SRKH and OTPMK registers are written to in the first board you used. If you burnt them or not and what is its value if positive.

Edit: Could you please confirm that when generating your keys, your OTPMKR_X are described starting from 0 AND the bits interval starting from 255?

Best regards