Verifying IVT data in memory on i.MX6 using memory dump

[MickeyI]

Hi,

I'm trying to get a signed u-boot image authenticated on i.MX6. I want to verify that the IVT struct in memory holds the correct pointers.

On the u-boot-signed.bin I can see the following on offset 0x400:

0x00000400: D1002040 20088027 00000000 2C048027

0x00000410: 20048027 00048027 00308327 00000000

According to freescale's HABv4 docs, the IVT looks like this:

typedef struct

{

  uint32_t header;

  uint32_t *entry;

  uint32_t reserved1;

  uint32_t *dcd;

  boot_data_t *boot_data;

  uint32_t *self;

  uint32_t *csf;

  uint32_t reserved2;

} image_vector_table_t;

The value corresponding the (uint32_t *) self field in the table is  0x27800400.

I expect to find the IVT table at that address, however memory dump command from u-boot shows zeros:

U-Boot > md 0x278003f0 0xc

278003f0: 00000000 00000000 00000000 00000000 

27800400: 00000000 00000000 00000000 00000000 

27800410: 00000000 00000000 00000000 00000000

Any ideas?

[AlanZhang]

Hi, Mickey,

i verified the uboot image generation process according to High_Assurance_Boot_L3.0.35_1.1.0.pdf packed in i.MX6Q 3.0.5_1.1.0_121218 release. The generated u-boot-signed-pad.bin is matched the anticipation as following:

000400: d1 00 20 40 e0 06 80 27 00 00 00 00 2c 04 80 27

......

I attached my u-boot.cst and habimagegen.sh file that you can reference. Pls note : The doc is based on old u-boot code. For example, the size of u-boot.bin is <=0x28000. But the actual generated u-boot size is 0x69817. You can see the size in u-boot.map as attached.

Regards,

Alan Zhang

[MickeyI · Accepted solution]

I downloaded the IMX6HABUG document (Rev L3.0.35_4.0.0, 05/2013), and retried the whole process on a new i.MX6 chip, so that the fuses are burned again. I have a clean HAB event log. My guess is something probably went wrong with burning the fuses the on the previous chip.

Thanks for your help!

[AlbertT]

Hello,

The value 0x27800400 is the self pointer of the IVT in DDR, that means when your whole signed u-boot will be transfered in DDR by the ROM, the IVT will be placed at 0x27800400.

If you can see the IVT at 0x400 of your binary, then it's ok.

Little tip, you can enable #DEBUG_AUTHENTICATE_IMAGE that will display more information when your uImage will be authenticated by the ROM.

Best regards,

[MickeyI]

I can't find the DEBUG_AUTHENTICATE_IMAGE ifdef's in the u-boot src (2009.08).

Are you using a special patch?

[AlbertT]

You have to define it, just like CONFIG_SECURE_BOOT, for instance in include/configs/<your_board>.h

[MickeyI]

I see CONFIG_SECURE_BOOT ifdefs in the code, but I don't see any ifdefs of DEBUG_AUTHENTICATE_IMAGE.

[AlbertT]

Yes, it's because it's the ROM which uses it. Actually I never tried to look for it in the u-boot code, but I know it works !

EDIT : after 10 sec of reflexion it seemed obvious to me that it wasn't used by the ROM, I looked in the code and you can see your flag used in cpu/arm_cortexa8/mx6/generic.c

[MickeyI]

I can't see it, please post a piece of code between that ifdef, I want to make sense out of it.

Anyway, still on the IVT subject - this is what the HAB user guide says (Rev L3.0.35_4.0.0, 05/2013):

ROM code copies U-Boot to DDR location 0x27800000, which is added with 0x400 (the initiated blank area size in U-

Boot image) to form the authenticated start address 0x27800400. 0x400 and 0x2EC00 is the start address and the length

of data to be authenticated in the binary file.

Can anyone who successfully implemented secure boot on the i.MX6 check and see if they can see the IVT at address 0x27800400?

[AlbertT]

Here you can find enclosed the function authenticate_image of the file generic.c which I told you.

And for you second question, I do, I can my IVT dumped by authenticate_image at 0x27800000.

[MickeyI]

Thanks for the code! I don't know why it doesn't appear in the u-boot I'm using.

I think I'm missing something about how the u-boot/HAB flow works. The code you sent me appears in the authenticate_image() function. Running grep on every u-boot source code for 'authenticate_image' shows that it is called only from inside cmd_bootm.c, which means that 'bootm' command must be invoked to enable 'authenticate_image'  code to run.

However, when I stop the u-boot flow and run 'hab_status' command in the u-boot prompt prior to running 'bootm' I already see a dirty HAB event log.

Where did those events come from? What made the HAB go to non-secure state?

If you stop at the u-boot prompt do you see a clean HAB event log?

[AlbertT]

The ROM tries to authenticate your u-boot, so prior the bootm command, the event you are seeing must come from this authentication. It means your u-boot isn't signed correctly.

Actually you can implement an authentication in other command than bootm, I have successfully authenticate an other OS which uses the "go" command instead of "bootm".

Moreover, if you look in the code of authenticate_image, you can see it tests if the imx6 is in closed state  :

if (check_hab_enable() == 1)

You have to modify it and recompile your u-boot to bypass this test if you want to authenticate your uImage and your imx6 is still in open configuration.

[MickeyI]

Any ideas how can this be debugged? a question I posted didn't get any replies yet (https://community.freescale.com/thread/308173)

I just want to be clear on one fact, sorry if this is the same question rephrased:

Do you see the IVT at address of 0x27800400 if you do memory dump from u-boot? Can you see non zero values at that address if you stop the u-boot flow, and at the command prompt invoke 'md 0x27800400'?

[AlbertT]

You have to understand that 0x27800000 is the address of the IVT in DDR, if you want to check the IVT in your u-boot.bin you have to look at the 0x400 of your binary.

[MickeyI]

I understand the differences between those two, I suspect that the IVT isn't being copied and this may be causing the signature failures. In the CSF file I ask the HAB to verify the data between the address of (DDR): 0x27800400 --> 0x27833000:

[Authenticate Data]

        Verification index = 2

        Engine = ANY

        Blocks = 0x27800400 0x400 0x32C00 "/path/to/u-boot/u-boot-pad.bin"

The range includes the IVT for the signed hash to protect it from being modified. If the data in 0x27800400 doesn't match the data that the encrypted hash was calculated on, there will be a diff in the results.

Address 0x400 on the device contains valid IVT, but what I see on address 0x27800400 using memory dump command contains all zeros where the IVT should be.

To understand if that's the reason I see dirty HAB events log I need to know if a clean HAB events log is possible while a memory dump on 0x27800400 shows only zeros.

[AlbertT]

Make sure your ivt is at the right place in your u-boot-signed-pad.bin :

xxd -l 20 -s 0x400 u-boot-signed-pad.bin

If you see "d100 2040 ..." that's ok

[MickeyI]

That's what I started with, I see valid IVT in the boot device.

AlbertT, what's your answer to the memory dump? If you stop u-boot and do: 'md 0x27800400', what do you see?