* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken @ 2019-07-30 11:00 Igor Opaniuk 2019-07-30 13:32 ` Bryan O'Donoghue 0 siblings, 1 reply; 10+ messages in thread From: Igor Opaniuk @ 2019-07-30 11:00 UTC (permalink / raw) To: u-boot Hi folks, Just curious if you ever faced any issues with HABv4 based secure boot on iMX7 SoC-based boards + NAND + mainline U-Boot (although it works perfectly when booting from eMMC). I'm currently playing with it on Colibri iMX7 NAND version, following all steps from [1], (colibri_imx7_defconfig, where CONFIG_SECURE_BOOT=y and CONFIG_FSL_CAAM=y, without these two options enabled it's booting ok) and facing the same issue as explained in one of NXP forum threads [2]. Taking into account that default BootROM doesn't provide any output at all to the serial console it is like looking for a needle in a haystack. Do you have any ideas about possible pitfalls/what could be missing in this puzzle? Or at least some hints where to look into? Thanks in advance! [1] https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/imx/habv4/guides/mx6_mx7_secure_boot.txt [2] https://community.nxp.com/thread/380130 -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 11:00 [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken Igor Opaniuk @ 2019-07-30 13:32 ` Bryan O'Donoghue 2019-07-30 13:56 ` Igor Opaniuk 0 siblings, 1 reply; 10+ messages in thread From: Bryan O'Donoghue @ 2019-07-30 13:32 UTC (permalink / raw) To: u-boot On 30/07/2019 12:00, Igor Opaniuk wrote: > Hi folks, > > Just curious if you ever faced any issues with HABv4 based > secure boot on iMX7 SoC-based boards + NAND + > mainline U-Boot (although it works perfectly when booting from > eMMC). > > I'm currently playing with it on Colibri iMX7 NAND version, > following all steps from [1], > (colibri_imx7_defconfig, where CONFIG_SECURE_BOOT=y > and CONFIG_FSL_CAAM=y, without these two options enabled > it's booting ok) and facing the same issue as explained > in one of NXP forum threads [2]. Taking into account that default > BootROM doesn't provide any output at all to the serial console it is like > looking for a needle in a haystack. When HAB authentication fails in the BootROM it should drop you back into serial download mode. Does that happen ? ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 13:32 ` Bryan O'Donoghue @ 2019-07-30 13:56 ` Igor Opaniuk 2019-07-30 14:02 ` Bryan O'Donoghue 0 siblings, 1 reply; 10+ messages in thread From: Igor Opaniuk @ 2019-07-30 13:56 UTC (permalink / raw) To: u-boot Hi Bryan, On Tue, Jul 30, 2019 at 4:32 PM Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote: > > > > On 30/07/2019 12:00, Igor Opaniuk wrote: > > Hi folks, > > > > Just curious if you ever faced any issues with HABv4 based > > secure boot on iMX7 SoC-based boards + NAND + > > mainline U-Boot (although it works perfectly when booting from > > eMMC). > > > > I'm currently playing with it on Colibri iMX7 NAND version, > > following all steps from [1], > > (colibri_imx7_defconfig, where CONFIG_SECURE_BOOT=y > > and CONFIG_FSL_CAAM=y, without these two options enabled > > it's booting ok) and facing the same issue as explained > > in one of NXP forum threads [2]. Taking into account that default > > BootROM doesn't provide any output at all to the serial console it is like > > looking for a needle in a haystack. > > When HAB authentication fails in the BootROM it should drop you back > into serial download mode. > > Does that happen ? Yes, it does. imx_usb detects it(15a2:0076(mx7)): config file <imx_flash/imx_usb.conf> vid=0x066f pid=0x3780 file_name=mx23_usb_work.conf vid=0x15a2 pid=0x004f file_name=mx28_usb_work.conf vid=0x15a2 pid=0x0052 file_name=mx50_usb_work.conf vid=0x15a2 pid=0x0054 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0061 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0063 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0071 file_name=mx6_usb_work.conf vid=0x15a2 pid=0x007d file_name=mx6_usb_work.conf vid=0x15a2 pid=0x0076 file_name=mx7_usb_work.conf vid=0x15a2 pid=0x0041 file_name=mx51_usb_work.conf vid=0x15a2 pid=0x004e file_name=mx53_usb_work.conf vid=0x15a2 pid=0x006a file_name=vybrid_usb_work.conf vid=0x066f pid=0x37ff file_name=linux_gadget.conf config file <imx_flash/mx7_usb_work.conf> parse imx_flash/mx7_usb_work.conf 15a2:0076(mx7) bConfigurationValue =1 Interface 0 claimed HAB security state: development mode (0x56787856) == work item filename colibri-imx7_bin/u-boot-nand.imx load_size 0 bytes load_addr 0x00000000 dcd 1 clear_dcd 0 plug 1 jump_mode 2 jump_addr 0x00000000 == end work item main dcd length 1b4 sub dcd length 164 sub dcd length c Check Data Command(10) success @307900c4=1d9 mask 1 sub dcd length 34 sub dcd length c Check Data Command(10) success @307a0004=1 mask 1 loading binary file(colibri-imx7_bin/u-boot-nand.imx) to 877ff400, skip=0, fsize=a2c00 type=aa <<<666624, 666624 bytes>>> succeeded (status 0x88888888) jumping to 0x877ff400 -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 13:56 ` Igor Opaniuk @ 2019-07-30 14:02 ` Bryan O'Donoghue 2019-07-30 14:08 ` Bryan O'Donoghue 0 siblings, 1 reply; 10+ messages in thread From: Bryan O'Donoghue @ 2019-07-30 14:02 UTC (permalink / raw) To: u-boot On 30/07/2019 14:56, Igor Opaniuk wrote: >> Does that happen ? > Yes, it does. And the board is closed ? ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 14:02 ` Bryan O'Donoghue @ 2019-07-30 14:08 ` Bryan O'Donoghue 2019-07-30 14:26 ` Igor Opaniuk 0 siblings, 1 reply; 10+ messages in thread From: Bryan O'Donoghue @ 2019-07-30 14:08 UTC (permalink / raw) To: u-boot On 30/07/2019 15:02, Bryan O'Donoghue wrote: > > > On 30/07/2019 14:56, Igor Opaniuk wrote: >>> Does that happen ? >> Yes, it does. > > And the board is closed ? Obviously yes it is. You have to sign the binary differently for serial download versus boot from eMMC - I guess this holds for NAND too. https://boundarydevices.com/high-assurance-boot-hab-dummies/ I have a serial download version of u-boot and an eMMC version for signed boards for that reason i.e. you can't use the same image. HAB for dummies explains it. --- bod ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 14:08 ` Bryan O'Donoghue @ 2019-07-30 14:26 ` Igor Opaniuk 2019-07-30 14:33 ` Bryan O'Donoghue 0 siblings, 1 reply; 10+ messages in thread From: Igor Opaniuk @ 2019-07-30 14:26 UTC (permalink / raw) To: u-boot Hi Bryan, On Tue, Jul 30, 2019 at 5:08 PM Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote: > > > > On 30/07/2019 15:02, Bryan O'Donoghue wrote: > > > > > > On 30/07/2019 14:56, Igor Opaniuk wrote: > >>> Does that happen ? > >> Yes, it does. > > > > And the board is closed ? Actually it's not. In U-boot stored to RAM via recovery: Colibri iMX7 # hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 --------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x08 0x42 0x33 0x22 0x0a 0x00 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ADDRESS (0x22) CTX = HAB_CTX_AUTHENTICATE (0x0A) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x08 0x42 0x33 0x22 0x0a 0x00 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ADDRESS (0x22) CTX = HAB_CTX_AUTHENTICATE (0x0A) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 3 ----------------- event data: 0xdb 0x00 0x08 0x42 0x33 0x22 0x0a 0x00 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ADDRESS (0x22) CTX = HAB_CTX_AUTHENTICATE (0x0A) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 4 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x00 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 5 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x80 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) > > Obviously yes it is. > > You have to sign the binary differently for serial download versus boot > from eMMC - I guess this holds for NAND too. > > https://boundarydevices.com/high-assurance-boot-hab-dummies/ > > I have a serial download version of u-boot and an eMMC version for > signed boards for that reason i.e. you can't use the same image. > > HAB for dummies explains it. > > --- > bod Anyway, let me go through this article one more time, and I'll get back to you. Thanks for suggestions! -- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 14:26 ` Igor Opaniuk @ 2019-07-30 14:33 ` Bryan O'Donoghue 2019-09-12 13:55 ` Igor Opaniuk 0 siblings, 1 reply; 10+ messages in thread From: Bryan O'Donoghue @ 2019-07-30 14:33 UTC (permalink / raw) To: u-boot 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" ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-07-30 14:33 ` Bryan O'Donoghue @ 2019-09-12 13:55 ` Igor Opaniuk 2019-09-16 2:54 ` Breno Matheus Lima 0 siblings, 1 reply; 10+ messages in thread From: Igor Opaniuk @ 2019-09-12 13:55 UTC (permalink / raw) To: u-boot Hy Bryan, Breno, On Tue, Jul 30, 2019 at 5:33 PM Bryan O'Donoghue <bryan.odonoghue@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-09-12 13:55 ` Igor Opaniuk @ 2019-09-16 2:54 ` Breno Matheus Lima 2019-09-16 8:42 ` Igor Opaniuk 0 siblings, 1 reply; 10+ messages in thread From: Breno Matheus Lima @ 2019-09-16 2:54 UTC (permalink / raw) To: u-boot Hi Igor, Em qui, 12 de set de 2019 às 10:55, Igor Opaniuk <igor.opaniuk@gmail.com> escreveu: > > Hy Bryan, Breno, > > On Tue, Jul 30, 2019 at 5:33 PM Bryan O'Donoghue > <bryan.odonoghue@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. > 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. > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken 2019-09-16 2:54 ` Breno Matheus Lima @ 2019-09-16 8:42 ` Igor Opaniuk 0 siblings, 0 replies; 10+ messages in thread From: Igor Opaniuk @ 2019-09-16 8:42 UTC (permalink / raw) To: u-boot Hi Breno, On Mon, Sep 16, 2019 at 5:54 AM Breno Matheus Lima <brenomatheus@gmail.com> wrote: > > Hi Igor, > > Em qui, 12 de set de 2019 às 10:55, Igor Opaniuk > <igor.opaniuk@gmail.com> escreveu: > > > > Hy Bryan, Breno, > > > > On Tue, Jul 30, 2019 at 5:33 PM Bryan O'Donoghue > > <bryan.odonoghue@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-09-16 8:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-30 11:00 [U-Boot] nxp: HABv4 secure boot on iMX7 NAND broken Igor Opaniuk 2019-07-30 13:32 ` Bryan O'Donoghue 2019-07-30 13:56 ` Igor Opaniuk 2019-07-30 14:02 ` Bryan O'Donoghue 2019-07-30 14:08 ` Bryan O'Donoghue 2019-07-30 14:26 ` Igor Opaniuk 2019-07-30 14:33 ` Bryan O'Donoghue 2019-09-12 13:55 ` Igor Opaniuk 2019-09-16 2:54 ` Breno Matheus Lima 2019-09-16 8:42 ` Igor Opaniuk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.