HAB, loading to OCRAM and software update

[matias_larsson]

Hi,

We have an i.MX7D and are using HAB on it. I have a couple of questions and hope someone can help.

First question. We have until now loaded the first-stage bootloader to OCRAM (0x918000) and booted from there. (This is a custom bootloader for what it's worth mentioning.) When booting a signed bootloader with SRK eFuses burned, we get the HAB_INV_ADDRESS event with HAB_CTX_TARGET as context. If I change the linker script so that the bootloader is loaded to DRAM, everything is fine, I get no HAB events. I have checked that the OCRAM address does not overlap with HAB persistent memory region according to https://www.nxp.com/docs/en/application-note/AN12263.pdf. One curious thing that I noticed in the event data is that HAB apparently tries to validate the region with a length of 0x10000000. See the event data below.

event data:
0xdb 0x00 0x14 0x42 0x33 0x22 0x33 0x00
0x00 0x00 0x00 0x0f 0x00 0x91 0x80 0x00
0x10 0x00 0x00 0x00

What could be the reason to this behavior from HAB? How does HAB decide the memory region length used in this operation?

By "firmware" I mean whatever the bootloader loads, i.e. non-bootloader software.

Second question. Do you have any recommendations for how to handle a firmware update? We would like to authenticate the image before flashing and of course before execution. I can come up with at least one solution but I wonder if there's a better/easier way. My solution is as follows. Make a separate (signed) image of the firmware updater code and load it to a known address in RAM that will not overlap with firmware. Then the new, updated firmware image can be loaded to the authenticated memory region (as specified in the CSF) and we can just call authenticate_image() from the updater code. This way we only need to authenticate the region where we inted to execute the firmware and nothing else. But then we need to maintain this extra updater image and handle its updates somehow as well.

What do you think, how should we handle the firmware updates?

BR,

Matias Larsson

[matias_larsson]

We have come accross another possible solution for firmware update that I'll share in case anyone else interested is reading this. Also any comments would be appreciated. This solution is simpler than the one I presented earlier.

Once the new firmware image is signed, the signed image is also signed, resulting in one "inner" and one "outer" signature. This way the "outer" HAB data blob can contain a different RAM address to authenticate than the inner one. This means that the image to be updated to doesn't have to be loaded to the code entry address. The outer signature has to be discarded at flashing.

This idea is still at a very theoretical level but we will take it into consideration at least.

[matias_larsson]

I can confirm now that this solution works. The trick is to have enough RAM to be able to reserve a region solely for the purpose of authenticating an update image.

[matias_larsson]

I should add that when I changed the load address, I also changed the address in the CSF [Authenticate Data] section.

[Yuri]

Hello,

   please look at my comments below.

1.

   The size of 0x10000000 is very big, generally the CSF file informs about checked areas.

Please double verify the CSF.

2.

  The idea of using special updater looks reasonable.

Have a great day,

Yuri

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

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

[matias_larsson]

Hi,

Thank you for your response. Below are the [Authenticate Data] sections from my CSF files for OCRAM and DRAM. The only difference between the two files is in that section.

OCRAM

[Authenticate Data]
 Verification index = 2
 Blocks = 0x918400 0x400 0x13f8 "preboot.tmp"

DRAM

[Authenticate Data]
 Verification index = 2
 Blocks = 0x80001400 0x400 0x13f8 "preboot.tmp"

Here are also the boot data contents as output by the below od command.

od -t x4 -j 0x420 -N 0xc bin/preboot-signed.y

OCRAM

00918000 00003800 00000000

DRAM

80001000 00003800 00000000

File sizes are as follows.

preboot.tmp:          6136 = 0x17f8 bytes

preboot-signed.y: 14328 = 0x37f8 bytes

I can't see where the length of 0x10000000 bytes comes from.

About the updater, can you think of some other way than what I suggested to handle a software update so that the image is authenticated by the update process? I'm looking for alternatives, preferably ones that require less effort.

[Yuri · Accepted solution]

Hello,

  I've sent You some comments directly.

Regards,

Yuri.