[U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken
Igor Opaniuk
igor.opaniuk at gmail.com
Mon Sep 16 08:42:42 UTC 2019
Hi Breno,
On Mon, Sep 16, 2019 at 5:54 AM Breno Matheus Lima
<brenomatheus at gmail.com> wrote:
>
> Hi Igor,
>
> Em qui, 12 de set de 2019 às 10:55, Igor Opaniuk
> <igor.opaniuk at gmail.com> escreveu:
> >
> > 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?
> >
>
> HAB will verify the image signature regardless of the SRK Hash fusing
> configuration, the SRK Hash is only used to validate the SRK table
> which is included in your CSF binary.
>
> In case your SRK Hash isn't programmed HAB won't validate the SRK
> table, but you can still see HAB events. You can have more details in
> section 4.1.1. SRK HASH and HAB events in open mode of AN4581.
Ok, got it.
>
> > 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.
> >
>
> Can you please confirm if your board is booting after enabling
> CONFIG_SECURE_BOOT in U-Boot? Can you please point me the U-Boot
> target are you trying? You should be able to boot in case your board
> still in open mode.
So there are two targets:
1. colibri_imx7_defconfig: NAND, doesn't boot with CONFIG_SECURE_BOOT=y
(currently enabled by default in the mainline).
I had discussion with Stefan Agner (cherry-picked) before, who introduced
edb411e2e6a ("configs: colibri_imx7: enable CAAM driver"), seems that U-boot
was tested only via USB recovery (no one tried to flash and boot it from NAND).
2. colibri_imx7_emmc_defconfig: similiar target, the only difference:
eMMC instead
NAND and 1GB DRAM,
Boots without any issues with CONFIG_SECURE_BOOT=y
(I don't even concatenate CSF region to imx binary).
>
> > 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?
> >
>
> When booting from NAND the DCD table is not loaded in OCRAM so that
> shouldn't be a problem. The DCD is loaded in OCRAM when booting via
> USB OTG using the serial download protocol, you can have more details
> in link below:
>
> https://github.com/NXPmicro/mfgtools/wiki/UUU-default-support-protocol-list#habv4-closed-chip-support
>
> > 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
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
> --
> Breno Matheus Lima
Thanks for looking into this!
--
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