From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Opaniuk Date: Mon, 16 Sep 2019 11:42:42 +0300 Subject: [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken In-Reply-To: References: <6a373006-65e5-191a-1ae7-d66bfaa66be5@linaro.org> <5c151f7d-f108-982f-b221-578a528c0c61@linaro.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Hi Breno, On Mon, Sep 16, 2019 at 5:54 AM Breno Matheus Lima wrote: > > Hi Igor, > > Em qui, 12 de set de 2019 às 10:55, Igor Opaniuk > escreveu: > > > > Hy Bryan, Breno, > > > > On Tue, Jul 30, 2019 at 5:33 PM Bryan O'Donoghue > > 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