cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
787 Views
Registered: ‎08-13-2019

DFU boot with authentication enabled

I am trying to enable secure boot mode when my Ultrascale is in USB DFU boot mode. I'm using bh_auth_enable to test this. I can successfully boot via DFU when secure boot is not enabled, and I can successfully boot via QSPI with secure boot enabled. This is what I see with secure DFU:

▒Xilinx Zynq MP First Stage Boot Loader
Release 0.1.24.01   Feb 22 2021  -  18:23:22
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU3CG
Processor Initialization Done
================= In Stage 2 ============
Multiboot Reg : 0x0
Image Header Table Offset 0x14000000
Error: Checksum 0xD3FFFFFF != 14000000
XFSBL_ERROR_IHT_CHECKSUM
Image Header Table Validation failed
Boot Device Initialization failed 0x21
================= In Stage Err ============
Fsbl Error Status: 0x00002021
Fallback not supported
Exit from FSBL

my bif files look like this:

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
	[pskfile] primary.pem
	[sskfile] secondary.pem
	[auth_params]spk_id = 0; ppk_select = 0
	[fsbl_config] a53_x64, bh_auth_enable
	[bootloader, authentication = rsa] fsbl.elf
	[pmufw_image] pmu.elf
}

for the first DFU file, and for the second:

//arch = zynqmp; split = false; format = BIN
the_ROM_image:
{
	[pskfile]C:\temp\bootbin\primary.pem
	[sskfile]C:\temp\bootbin\secondary.pem
	[auth_params]spk_id = 0; ppk_select = 0
	[fsbl_config]a53_x64, bh_auth_enable
	[bootloader, authentication = rsa] fsbl.elf
	[authentication = rsa, destination_device = pl] pl.bit
	[authentication = rsa, destination_cpu = a53-0, exception_level = el-3, trustzone] atf.elf
	[authentication = rsa, destination_cpu = a53-0, exception_level = el-2] u-boot.elf
}

 

My fsbl is compiled with 

#define FSBL_NAND_EXCLUDE_VAL			(0U)
#define FSBL_QSPI_EXCLUDE_VAL			(1U)
#define FSBL_SD_EXCLUDE_VAL			(1U)
#define FSBL_SECURE_EXCLUDE_VAL			(0U)
#define FSBL_BS_EXCLUDE_VAL			(0U)
#define FSBL_EARLY_HANDOFF_EXCLUDE_VAL		(1U)
#define FSBL_WDT_EXCLUDE_VAL			(0U)
#define FSBL_PERF_EXCLUDE_VAL			(1U)
#define FSBL_A53_TCM_ECC_EXCLUDE_VAL		(1U)
#define FSBL_PL_CLEAR_EXCLUDE_VAL		(1U)
#define FSBL_USB_EXCLUDE_VAL			(0U)
#define FSBL_PROT_BYPASS_EXCLUDE_VAL		(1U)
#define FSBL_PARTITION_LOAD_EXCLUDE_VAL 	(0U)
#define FSBL_FORCE_ENC_EXCLUDE_VAL		(0U)
#define FSBL_DDR_SR_EXCLUDE_VAL			(1U)

(that is, I've excluded QSPI and SD and included USB)

The bootgen_utility reports:

[0x00000098]         (0x98)        Image Header Table Offset            -   0x8c0
<snip>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::::::::::::::::::::::::::::::::::   I M A G E    H E A D E R    T A B L E   :::::::::::::::::::::::::::::::::
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Flash Address>     <Offset>            <Description>                     <Interpretation>

[0x000008c0]         (0x00)        Version                              -   0x1020000
[0x000008c4]         (0x04)        Count of Image Headers               -   0x06
[0x000008c8]         (0x08)        Offset to 1st Partition Header (Word)-   0x440
[0x000008cc]         (0x0c)        Offset to 1st Image Header (Word)    -   0x240
[0x000008d0]         (0x10)        Offset to Header Auth. Cert. (Word)  -   0x650
[0x000008d4]         (0x14)        Boot Device Type                     -   0x00
                                                                          # Boot Device : [None]
[0x000008fc]         (0x3c)        Image Header Table Checksum          -   0xfefdf329

 

I'm using the Xilinx SDK 2019.1 (and Petalinux 2019.1).

Why is the IHT checksum failing?

 

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

I am not sure but can you try these two options?

1. authenticate the pmufw as well in the first image.

OR

2. tyr to load the pmufw as partition (destination_cpu = pmu) from the second image rather than the first image.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
668 Views
Registered: ‎08-13-2019

Ok, it turns out you can't set the pmufw as authenticated when loading it via BootROM, so I removed it from the first image and added it to the second image. This resulted in the same behavior. 

The Image Header Table Offset looks totally bogus: 0x14000000, which is probably why the checksum is failing. I don't think anything is wrong with the second image, I loaded a non-authenticating first image and then the second image and I saw the expected value for the IHT offset:

================= In Stage 2 ============
Multiboot Reg : 0x0
Image Header Table Offset 0x8C0

 

0 Kudos
560 Views
Registered: ‎08-13-2019

If I add 

XFsbl_Printf(DEBUG_INFO, "Addr: %08X Length: %d\n", DestAddress, Length);
if (Length >= 0x9C) {
    XFsbl_PrintArray(DEBUG_INFO, (const u8*)DestAddress, 0x9C, "header");
}

to the end of XFsbl_UsbCopy, then I see this when USB booting using a boot.bin in non-authenticated mode:

================= In Stage 2 ============
Multiboot Reg : 0x0
Addr: FFFF1C40 Length: 3776
                           header START
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
66 55 99 AA 58 4E 4C 58 00 00 00 00 00 00 FC FF
00 28 00 00 00 00 00 00 00 00 00 00 10 94 01 00
00 A3 01 00 00 C8 00 00 31 35 1A FD 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 C0 08 00 00
header END
Image Header Table Offset 0x8C0

But in authenticated mode, it looks like the first 32-bytes get duplicated over the entire area:

================= In Stage 2 ============
Multiboot Reg : 0x0
Addr: FFFF1C40 Length: 3776
                           header START
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14
header END
Image Header Table Offset 0x14000000

 

 

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

Do you mind printing the DfuVirtFlash and SrcAddress before the XFsbl_UsbCopy() ?

I would like to understand if the failure is with the XCsuDma_Transfer() or before.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
504 Views
Registered: ‎08-13-2019

Authenticated:

================= In Stage 2 ============
Multiboot Reg : 0x0
CSU_CSU_SSS_CFG: 00005050 DfuVirtFlash: 04000000 SrcAddress: 00000000
Addr: FFFF1C40 Length: 3776

non-authenticated:

================= In Stage 2 ============
Multiboot Reg : 0x0
CSU_CSU_SSS_CFG: 00000050 DfuVirtFlash: 04000000 SrcAddress: 00000000
Addr: FFFF1C40 Length: 3776

 

It looks like the difference is that the SSS has the DMA to SHA destination additionally selected. If I mask that out (so SSS is set to 0x50) the transfer completes successfully and I get a valid IHT offset. I'm not sure why that would make a difference. 

In any case, the load fails later on now:

▒Xilinx Zynq MP First Stage Boot Loader
Release 0.1.25.01   Mar 16 2021  -  18:38:49
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU3CG
Processor Initialization Done
================= In Stage 2 ============
Multiboot Reg : 0x0
CSU_CSU_SSS_CFG: 00000050 DfuVirtFlash: 04000000 SrcAddress: 00000000
Addr: FFFF1C40 Length: 3776
header START
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
00 00 00 14 00 00 00 14 00 00 00 14 00 00 00 14
66 55 99 AA 58 4E 4C 58 00 00 00 00 00 00 FC FF
00 28 00 00 00 00 00 00 00 00 00 00 10 94 01 00
00 A3 01 00 00 C8 00 00 31 35 1A FD 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 C0 08 00 00
header END
Image Header Table Offset 0x8C0
Authentication Enabled
CSU_CSU_SSS_CFG: 00000050 DfuVirtFlash: 04000000 SrcAddress: 000008D0
Addr: FFFDDC9C Length: 4
CSU_CSU_SSS_CFG: 00000050 DfuVirtFlash: 04000000 SrcAddress: 00001940
Addr: FFFDA650 Length: 3776
header START
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9A 13 27 76 39 E9 AC 40 D5 F1 DA 1B 20 02 50 E2
A1 D2 AA 8F 26 A4 15 F6 8F 3F 8D 1B 9A E2 8B 7C
D1 1B 6F 52 E2 45 DE 67 F2 8E 01 BE E4 98 A7 A2
DC 43 49 5D 37 E0 E5 BD 2F 63 E1 19 D1 E2 C0 40
F1 72 58 95 24 C8 01 8D 7D E3 F5 18 A9 CF A2 D0
6D 95 33 81 DF 92 6E 07 43 4C 67 AD
header END
Invalid SpkIdFuseSel: 0
 : XFsbl_SpkVer: XFSBL_ERROR_INVALID_EFUSE_SELECT
Failure at boot header authentication
Boot Device Initialization failed 0x74
================= In Stage Err ============
Fsbl Error Status: 0x00002074
Fallback not supported
Exit from FSBL

Again, this is with the bif files from above, with the exception that the PMU is now loaded in the second bin after the PL. 

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

Engineering is looking into this to try to reproduce and debug.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
255 Views
Registered: ‎08-13-2019

Any updates on this?

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

Engineering found the issue with a configuration of the SSS and this is going to be fixed in 2021.1.

As a temporary fix you can try to modify lib/sw_apps/zynqmp_fsbl/src/xfsbl_usb.c to Clear CSU_SSS_CFG register in XFsbl_UsbCopy to clear SHA and AES nibbles and avoid DMA corrupting destination data.

/* Setup the SSS for DMA */

u32 RegVal = XFsbl_In32(CSU_CSU_SSS_CFG) & XFSBL_CSU_SSS_DMA_MASK;

u32 RegVal1 = RegVal | XFSBL_CSU_SSS_SRC_DEST_DMA;

XFsbl_Out32(CSU_CSU_SSS_CFG, RegVal1);

XFsbl_Out32(CSU_CSU_SSS_CFG, XFSBL_CSU_SSS_SRC_DEST_DMA);

 

 

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

Should have AR#76410 become public in the next few days.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
105 Views
Registered: ‎08-13-2019

I tried the workaround (that you listed above, not AR#76410 which I can't see yet), and it allowed the header to load correctly, but the AC still seems to have an issue when loading:
bootgen -read excerpt from the second .bin file:

--------------------------------------------------------------------------------
   AUTHENTICATION CERTIFICATE (Headers)
--------------------------------------------------------------------------------
         auth_header (0x00) : 0x00040115
              spk_id (0x04) : 0x00000000
                 udf (0x08) : 000000000000000000000000000000000000000000000000
                              000000000000000000000000000000000000000000000000
                              0000000000000000
             ppk_mod (0x40) : 9a13277639e9ac40d5f1da1b200250e2a1d2aa8f26a415f6


And here's the output from the bootloader:

Image Header Table Offset 0x8C0
Authentication Enabled
SSS: 00000050 Src: 000008D0 Dst: FFFDFC6C Length: 4
data START
50 06 00 00
data END
SSS: 00000050 Src: 00001940 Dst: FFFDC648 Length: 3776
data START
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9A 13 27 76 39 E9 AC 40 D5 F1 DA 1B 20 02 50 E2
A1 D2 AA 8F 26 A4 15 F6 8F 3F 8D 1B 9A E2 8B 7C
D1 1B 6F 52 E2 45 DE 67 F2 8E 01 BE E4 98 A7 A2
DC 43 49 5D 37 E0 E5 BD 2F 63 E1 19 D1 E2 C0 40
F1 72 58 95 24 C8 01 8D 7D E3 F5 18 A9 CF A2 D0
6D 95 33 81 DF 92 6E 07 43 4C 67 AD 3A B2 58 9D

data END
Invalid SpkIdFuseSel: 0, auth_header: 00000000
 : XFsbl_SpkVer: XFSBL_ERROR_INVALID_EFUSE_SELECT
Failure at boot header authentication
Boot Device Initialization failed 0x74

The start location for the AC seems correct (0x1940 agrees with the bootgen -read printout) but as you can see the first 4 bytes in the AC should be 0x00040115 instead of the 0x0000000 that I'm seeing. 

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

If this file attached doesn't work let me know.

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