[U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken

Igor Opaniuk igor.opaniuk at gmail.com
Thu Sep 12 13:55:09 UTC 2019


Hy Bryan, Breno,

On Tue, Jul 30, 2019 at 5:33 PM Bryan O'Donoghue
<bryan.odonoghue at linaro.org> wrote:
>
>
>
> On 30/07/2019 15:26, Igor Opaniuk wrote:
> > Anyway, let me go through this article one more time,
> > and I'll get back to you.
>
> If I've understood you, you are using the same binary for serial
> download and flash booting.
>
> Won't work unfortunately - there's an extra DCD directive in the
> recovery image.
>
> Here's my recovery CSF
>
> deckard at event-horizon:~/Development/mbl-u-boot$ cat uboot-c-s-f-recover.txt
> # SPDX-License-Identifier:      GPL-2.0
> [Header]
> Version = 4.1
> Security Configuration = Open
> Hash Algorithm = sha256
> Engine Configuration = 0
> Certificate Format = X509
> Signature Format = CMS
> Engine = CAAM
>
> [Install SRK]
> File = "SRK_1_2_3_4_table.bin"
> Source index = 0
>
> [Install CSFK]
> File = "CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
>
> [Authenticate CSF]
>
> [Install Key]
> # Key slot index used to authenticate the key to be installed
> Verification index = 0
> # Key to install
> Target index = 2
> File = "IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
>
> [Authenticate Data]
> Verification index = 2
> Blocks = HAB_BLOCKS_REPLACE "IMAGE_IMX_HAB_NAME_REPLACE"
>
> [Authenticate Data]
> Verification index = 2
> Blocks = DCD_BLOCKS_REPLACE "IMAGE_IMX_DCD_NAME_REPLACE"
>
> and my eMMC CSF
>
> deckard at event-horizon:~/Development/mbl-u-boot$ cat uboot-c-s-f.txt
> # SPDX-License-Identifier:      GPL-2.0
> [Header]
> Version = 4.1
> Security Configuration = Open
> Hash Algorithm = sha256
> Engine Configuration = 0
> Certificate Format = X509
> Signature Format = CMS
> Engine = CAAM
>
> [Install SRK]
> File = "SRK_1_2_3_4_table.bin"
> Source index = 0
>
> [Install CSFK]
> File = "CSF1_1_sha256_2048_65537_v3_usr_crt.pem"
>
> [Authenticate CSF]
>
> [Install Key]
> # Key slot index used to authenticate the key to be installed
> Verification index = 0
> # Key to install
> Target index = 2
> File = "IMG1_1_sha256_2048_65537_v3_usr_crt.pem"
>
> [Authenticate Data]
> Verification index = 2
> Blocks = HAB_BLOCKS_REPLACE "IMAGE_IMX_HAB_NAME_REPLACE"

So I've finally got back to this issue.
I've spent some time digging into links you provided and
 `Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using HABv4` doc
from NXP [1]. Some observations/statements I made (correct me if I'm
wrong) + questions:

1. Based on information from [1],  if SRK isn't fused and device isn't "closed",
BootROM HABv4 component actually doesn't care about CSF region at all.
In case if SRK is fused, but device is still in "open" state, it
performs verification of
binary (IVT + Boot Data + DCD Table + U-boot itself), but it continue loading
U-boot  regardless of the verification results (but in case of invalid signature
we will  observe HABv4 events by running `hab_status`). Is it correct?

2. I tried to boot U-boot on i.MX7D rev1.3 NAND with concatenated CSF binary
built using the configuration file you provided and without it (no
fuses are fused) -
in both cases it doesn't boot.

3. When `CSF` CMD is removed from imximage.cfg, the image starts booting,
so obviosly I assumed that something was wrong with IMX image layout
and how it's
stored in OCRAM. After analizing IVT table values and input from mkimage for the
final u-boot-dtb.imx, found out that DCD table is loaded to 0x00910000 (OCRAM):

Image Type:   Freescale IMX Boot Image
Image Ver:    2 (i.MX53/6/7 compatible)
Mode:         DCD
Data Size:    659456 Bytes = 644.00 KiB = 0.63 MiB
Load Address: 877ff420
Entry Point:  87800000
HAB Blocks:   0x877ff400 0x00000000 0x0009cc00
DCD Blocks:   0x00910000 0x0000002c 0x000001b4
                       ^^^^^^^^^^^^

In [1] F.1. Signing code downloadable with the manufacturing tool from the
document about Secure Boot, found the NOTE which says:

"Due to an issue with i.MX7D Rev D, the first 4K of OCRAM is not
available during boot time, on this case users must set the image start
address greater or equal to 0x911000. For more details please check
E11166 in Mask Set Errata for Mask 3N09P."

E11166 description in [2]:
"e11166: OCRAM: The first 4K of OCRAM (0x910000 - 0x910fff) is not
available during
boot time

Description: The first 4K of OCRAM (0x910000 – 0x910fff) is not available
during boot time which effects plug-ins and custom boot images.Using
this space may
cause image corruption during boot time. At time of boot failure, the system may
enter into serial download mode.

Workaround: Users must set the boot or plugin image start address greater or
equal to 0x911000 (if the boot image or plug-in is running in OCRAM).
Alternatively,
users can use a boot/plugin image load address in the external DDR
memory instead of
the internal OCRAM."

Could it be the root cause why I'm facing this issue?

4. BTW,  is there any publicly available information about analysis of
BootROM log buffer
that can be obtained by reading data pointed by Log Buffer Pointer (at
0x000001E0)
on iMX7?

[1] https://www.nxp.com/docs/en/application-note/AN4581.pdf
[2] https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf


Looking forward for your replies/comments.
Thanks!

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk


More information about the U-Boot mailing list