Unable to get signed or encrypted image to run on RT1020

[rshipman]

Hi,

I am unable to get signed or encrypted image to run on RT1020

I have two RT1020 eval boards.

One has the SRK fuses blown and the HAB closed fuse blown.

The other is unchanged from out of the box.

I am attempting to run a signed (and an encrypted) image in ITCM at start address 0.

I am using the iled_blinky demo, linked to start at 0x00002000.

I have two versions of this demo, a fast flash and the default (slow) flash.

I have successfully managed to download both of these onto the eval board with no fuses blown (unencrypted versions).

I have not managed to do the same with a signed or encrypted image onto the eval board with fuses blown.

I have successfully created a signed flashloader and downloaded that to the eval board (with fuses blown).

Trying to download an unsigned flashloader fails, so I am fairly confident that I have blown the fuses
correctly. The signed flashloader writes to and reads back from flash and internal memory successfully.

Please find attached the following zip files:

----------------------------------

iled_blinky_itcm_unencrypted_at_0x0000.zip

My successful attempt at an unencrypted image. Please see ./slow_com7 and ./fast_com7 scripts (for linux terminal).

The scripts run successfully to the end. When I set the dip switches for internal boot, the led flashes at the appropriate speed depending on the program I have loaded.

----------------------------------

iled_blinky_itcm_signed_at_0x0000.zip

My attempt at a signed image. Please see ./slow_experiment script (for linux terminal).

The script runs successfully to the end. When I set the dip switches for internal boot, the led does not flash.

----------------------------------

iled_blinky_itcm_encrypted_at_0x0000.zip

My attempt at an encrypted image. Please see ./slow_experiment script (for linux terminal).

The script runs successfully to the end. When I set the dip switches for internal boot, the led does not flash.

----------------------------------

signed_flashloader.zip

The signed flashloader that I use successfully on the eval board with the SRK fuses blown.

----------------------------------

SignedImageProblem.zip

Contains screenshots of NXP-MCUBootUtility of the signed attempt:

signed_image_problems_01.png   The fuses on the eval board.

signed_image_problems_02.png   The ivt at 0x60001000

signed_image_problems_03.png   The program image at 0x60002000

signed_image_problems_04.png   The CSF signature data at 0x60007000

----------------------------------

Sorry it's a lot of data, but if you look at the scripts it will be clear what I have been doing.

Is there anything obvious that I am doing with the signed/encrypted versions that means they won't run please?

Any help much appreciated.

[victorjimenez]

Hello, 

First I would like to apologize for the late response. I highly recommend you to follow the i.MX RT Secure Boot Lab Guide that is shown in the following link, i.MX RT Secure Boot Lab Guide.pdf. This lab gives a step-by-step guide on how to make a secure boot. Although the lab was made with an RT1050, the same applies to the RT1020. 

Additional to that, I would also recommend you take a look at the MCUBootUtility. This tool was made by a coworker, and it's really helpful when you are trying to make a secure boot and run an encrypted image. GitHub - JayHeng/NXP-MCUBootUtility: A one-stop boot utility tool based on Python2.7+wxPython4.0, it...  

Best regards, 

Victor 

[rshipman]

Thanks Victor. I had a look at the lab guide, it seems similar to the document AN12079.pdf, which I have followed.

I have been able to get signed flash XIP and flash->sram images to run on an RT1050-EVKB board (with SRK_HASH fuses burnt). And I can get the signed flash XIP to work on the RT1020-EVK board (With SRK_HASH fuses burnt). I just cannot get the signed flash->sram image to run on the same RT1020-EVK.

[victorjimenez]

Hello, 

Thanks for sharing more information with me! I'm currently checking this thread and the other two community questions that you have (RT1020 & RT1050: How is the MPU configured during boot ? and RT1050 - why am I getting HAB_WARNING: HAB_UNS_ENGINE/HAB_CTX_COMMAND ?) directly with our applications team. I will do my best to get a response as soon as possible. Thanks a lot for your patience and your understanding. 

Regards, 

Victor 

[victorjimenez]

Hello, 

RT1020/RT1015 has some limitations compared to other parts:
• HAB encrypted mode is not applicable for FlexSPI/SEMC NOR device boot, No matter it is XIP boot or Non-XIP boot.
• HAB signed mode is not applicable for FlexSPI/SEMC NOR device Non-XIP boot, but it works for XIP boot.

Best Regards, 

Victor 

[rshipman]

Thanks Victor.

So NAND will work ok.

Sounds like a silicon bug to me - are we getting a new revision soon? ;-)

[victorjimenez]

Hello, 

This is a limitation on RT1020/RT1015, however, there are no plans for future releases of these chips. 

Regards, 

Victor 

[rshipman]

I've used JTAG to look at the memory locations in ITCM (on the eval board with blown fuses) after loading my signed version of the image into flash (and attempting an internal boot). The ITCM memory is all random. So there is no IVT at 0x00001000, no app data at 0x00002000, and no CSF at 0x00007000. Those are the locations where I would expect them. That is where they are on the unsigned/unencrypted version (which works ok).

So inital boot copy is not happening on the eval board with blown fuses.

DIP switches are definitely in internal boot mode.

The corresponding locations in flash (ivt:0x60001000, app:0x60002000, csf:0x60007000) all make sense.

The ivt makes sense:

0x60001000 402000D1 000022C9 00000000 00000000 Ñ. @É"..........
0x60001010 00001020 00001000 00007000 00000000 ........p......
0x60001020 00000000 00009000 00000000 00000000 ................
0x60001030 00000000 00000000 00000000 00000000 ................

Is there something else I need to set or a fuse to blow to make the inital boot copy work in HAB closed mode?

According to the flow chart in section "8.3.2 High-level boot sequence" of the document "i.MX RT1020 Processor Reference Manual, Rev. 1, 12/2018", the initial boot load is performed before any authentication, which makes sense. So why is the ivt etc not being copied to ITCM?

[rshipman]

I have extracted the HAB event log.

Here it is for the signed version of the image:

------------+----+------+----+-------------------------------------------------
Persistent | T | L | P | Contents
Memory | a | e | a |
Record | g | n | r |
Type | | g | |
| | t | |
| | h | |
------------+----+------+----+-------------------------------------------------
Event |0xdb|0x0014|0x43| SRCE Field: 33 22 33 00
| | | | STS = HAB_FAILURE (0x33)
| | | | RSN = HAB_INV_ADDRESS (0x22)
| | | | CTX = HAB_CTX_TARGET (0x33)
| | | | ENG = HAB_ENG_ANY (0x00)
| | | | Evt Data (hex):
| | | | 00 00 00 0f 00 00 00 00 0f 7f ff fc
------------+----+------+----+-------------------------------------------------
Event |0xdb|0x0008|0x43| SRCE Field: 33 1e 0a 00
| | | | STS = HAB_FAILURE (0x33)
| | | | RSN = HAB_INV_RETURN (0x1E)
| | | | CTX = HAB_CTX_AUTHENTICATE (0x0A)
| | | | ENG = HAB_ENG_ANY (0x00)
------------+----+------+----+-------------------------------------------------

Which means the hab_rvt.check_target parameters were:

Type: 0x0000000f

Start: 0x00000000

Bytes: 0x0f7ffffc

Why is it complaining about the start address? That is where I am putting my image after all.

And the bytes field seems to be way too large. I just can't see where it is getting that from.

Not from the IVT as far as I can tell.

Note that I tried redoing the images to start at 0x2000 (so app starts at 0x4000). Just in case there is some issue about starting at 0x00000000 when in HAB mode. I get the same results. The unsigned/unencrypted images work fine, the signed does not. Also the start address in the event log above changes to 0x00002000 as you might expect. Otherwise exactly the same behaviour.

[rshipman]

I also tried with the signed image starting at 0x60000000, so running from flash. App linked to start at 0x60002000 etc. This worked. HAV event log was empty. So the signed version can run on the eval board with blown SRK fuses, as long as it stays in flash. So something is preventing my signed image from running from internal ram. I just cannot figure out what. Or where that "Bytes: 0x0f7ffffc" number is coming from in the HAB event log.

[rshipman]

I was just wondering if anybody had any thoughts on this?

[rshipman]

I tried another experiment. As I mentioned before the signed version works if it is linked to be in flash, at 0x60002000. So the ivt is at 0x60001000 and the start of the whole image is at 0x60000000. So the boot data is:

Start: 0x60000000

Length: 0x00009000

Plugin: 0x00000000

As expected.

This works.

As an experiment I nobbled the start address in the boot data to be 0x00007000. (A random internal address.)

When I change the dip switches for internal boot and reconnect the power I get a HAB event. Exactly the same as before except the start address in the event data field is 0x00007000. So with the HAB closed, the RT1020 just does not seem to like internal addresses. What am I missing here?

The event log:

------------+----+------+----+-------------------------------------------------
Persistent | T | L | P | Contents
Memory | a | e | a |
Record | g | n | r |
Type | | g | |
| | t | |
| | h | |
------------+----+------+----+-------------------------------------------------
Event |0xdb|0x0014|0x43| SRCE Field: 33 22 33 00
| | | | STS = HAB_FAILURE (0x33)
| | | | RSN = HAB_INV_ADDRESS (0x22)
| | | | CTX = HAB_CTX_TARGET (0x33)
| | | | ENG = HAB_ENG_ANY (0x00)
| | | | Evt Data (hex):
| | | | 00 00 00 0f 00 00 70 00 0f 7f ff fc
------------+----+------+----+-------------------------------------------------
Event |0xdb|0x0008|0x43| SRCE Field: 33 1e 0a 00
| | | | STS = HAB_FAILURE (0x33)
| | | | RSN = HAB_INV_RETURN (0x1E)
| | | | CTX = HAB_CTX_AUTHENTICATE (0x0A)
| | | | ENG = HAB_ENG_ANY (0x00)
------------+----+------+----+-------------------------------------------------

[rshipman]

I found this article:

https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2018/08/10/overview-of-using-the-... 

It refers to a document "RT1020_BriefOverview_v100.pdf" that has the following line: "The IMXRT1020 boots with a Memory Protecton Unit (MPU) setng that disables access to onchip SRAM."

So that would explain why I am unable to get the signed/encrypted images to run in internal SRAM.

The HAB error I have seen makes sense now.

Also when I look at the HAB event logs on the eval board (that has no efuses blown by me) with a working unsigned image, I get 6 HAB event errors - all relating to HAB_INV_ADDRESS or HAB_INV_ASSERTION (with HAB_ASSERT_BLOCK as the assertion type). So all bad access errors, which I believe are cause by the MPU.

So the question is, are we basically not meant to be booting from flash to internal memory on the RT1020?

I have tried to use a DCD to disable the MPU but I got this HAB error (which I think makes sense, as what you can do with the DCD is understandably restricted):

------------+----+------+----+-------------------------------------------------
Persistent | T | L | P | Contents
Memory | a | e | a |
Record | g | n | r |
Type | | g | |
| | t | |
| | h | |
------------+----+------+----+-------------------------------------------------
Event |0xdb|0x0014|0x43| SRCE Field: 33 22 c0 00
| | | | STS = HAB_FAILURE (0x33)
| | | | RSN = HAB_INV_ADDRESS (0x22)
| | | | CTX = HAB_CTX_COMMAND (0xC0)
| | | | ENG = HAB_ENG_ANY (0x00)
| | | | Cmd Field: 0xcc000c0c
Error: Unknown command

The DCD:

D2 00 10 41
CC 00 0C 0C
E0 00 ED 94
00 00 00 01

Which basically resets bit 0 in the MPU Control Register (0xE000ED94 MPU_CTRL) to disable it.

I notice that the RT1020_connect.scp script used by MCU Xpresso disables the MPU before it loads the image onto the board.

The boot loader ignores the HAB errors when HAB is open (i.e. no fuses blown), which is why my unsigned/unencrypted images all worked ok.

Some more questions:

1. There is an eFuse called BT_MPU_DISABLE (0x470[1]) which disables the MPU during boot if set. What are the security implications of blowing this fuse? I.e. Does blowing this fuse compromise security?

2. Can the MPU be reactivated via software running on the ARM?

3. I believe the RT1050 allows booting from flash to internal SRAM. Is this correct? If so, why the difference between the RT1020 and RT1050?

[rshipman]

As an experiment, on the closed eval board I set the eFuse BT_MPU_DISABLE (which disables the MPU during boot).

I was hoping disabling the MPU would circumvent the flash->sram boot problem, but it does not make a difference.

I can get the equivalent flash->sram image working on the RT1050 (signed image, SRK fuses burnt), so I fail to see why the RT1020 does not work. (FYI, the RT1050 gives me a HAB_WARNING regarding choice of engine, but that is a separate issue: https://community.nxp.com/thread/522887 )