Introduction
The Data Co-Processor (DCP) module available in i.MX 6ULZ, i.MX 6ULL, i.MX 6SLL and i.MX 6SL devices provide support for the general encryption and hashing functions.
The DCP feature can be used by HAB to accelerate SHA-256 operations improving the image authentication time, it can be enabled by defining "Engine = DCP" in the CSF file header.
Known Limitations
For a correct usage of DCP engine the following limitations should be considered when signing images to be processed by DCP engine.
1 - Wrong cache handling in i.MX 6ULL and i.MX 6ULZ devices
Due to an issue with the ROM code the HAB does not invalidate D-Cache when reading back the Hash generated by DCP, as the value processed by HAB is "wrong" the following HAB failure event is reported and target fails to boot in closed mode:
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x14 0x42 0x33 0x18 0xc0 0x00
0xca 0x00 0x0c 0x00 0x01 0xc5 0x1b 0x00
0x00 0x00 0x07 0xdcSTS = HAB_FAILURE (0x33)
RSN = HAB_INV_SIGNATURE (0x18)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)
The DCP engine can still be used by HAB with d-cache disabled, this can be achieved by following the steps below:
1.1 - BootROM level
D-cache can be disabled at ROM level by programming BT_MMU_DISABLE fuse (0x470[1]):
=> fuse prog 0 7 0x00000002
1.2 - U-Boot level
The BT_MMU_DISABLE fuse only disables d-cache at BootROM level, U-Boot is re-enabling d-cache by default. The following command can be used to disable d-cache prior to authenticate Linux Kernel image:
=> dcache off
Additional details can be found in chip errata "ERR010449 System Boot: HAB HAL routine hab_hal_invalidate_cache should invalidate L1/L2 D-cache, but did not in the ROM code".
2 - Authenticate data length must be 64 bytes aligned
HAB requires chained hashing operations (operations involving multiple descriptors), every descriptor except the last must have a byte count that is a 16-word multiple (granularity of the hash algorithm).
In case the authenticate data length is not 64 bytes multiple the following HAB Warning event is generated and SW implementation is used instead.
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x24 0x42 0x69 0x0a 0xc0 0x00
0xca 0x00 0x1c 0x00 0x02 0xc5 0x1b 0x00
0x00 0x00 0x0d 0x3c 0x87 0x7f 0xf4 0x00
0x00 0x00 0x03 0x0c 0x87 0x7f 0xf4 0x00
0x00 0x09 0x4b 0x1cSTS = HAB_WARNING (0x69)
RSN = HAB_UNS_ENGINE (0x0A)
CTX = HAB_CTX_COMMAND (0xC0)
ENG = HAB_ENG_ANY (0x00)
As only a HAB warning event is generated the target can still boot, please note that hashing operation in SW is slower than in DCP engine.
This limitation only applies to users signing multiple blocks in authenticate data command, the example below can be processed by DCP.
[Authenticate Data]
Verification index = 2
Blocks = 0x80800000 0x00000000 0x00000040 "zImage_pad_ivt.bin", \
0x80801000 0x00001000 0x006ee020 "zImage_pad_ivt.bin"
References
- Additional details about DCP block can be found in the respective SoC Security Reference Manual.
- Additional details can be found in the chip errata
