Skip to content

Commit

Permalink
LFU-457: Update 8ulp/93 secure boot documentation
Browse files Browse the repository at this point in the history 
- Add 93 references including secure boot flow
- Upower only required in 8ULP
- Followed naming convention for ELE FW

Signed-off-by: Utkarsh Gupta <[email protected]>
Reviewed-by: Ye Li <[email protected]>
  • Loading branch information
@utkarshguptanxp
utkarshguptanxp authored and Ye Li committed Jan 31, 2023
1 parent 5e2cfe2 commit 97054dd
Show file tree
Hide file tree
Showing 3 changed files with 89 additions and 47 deletions.
61 changes: 30 additions & 31 deletions doc/imx/ahab/guides/mx8ulp_secure_boot.txt → ...imx/ahab/guides/mx8ulp_9x_secure_boot.txt
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
+=========================================================+
+ i.MX 8ULP AHAB guide using AHAB +
+ i.MX 8ULP/9x Secure boot guide using AHAB +
+=========================================================+

1. AHAB secure boot process
Expand All @@ -25,8 +25,8 @@ to sign the image.

Based on bootmode, following files are needed to prepare the boot image:
- All boot modes
- Edgelock secure enclave Firmware (ELke).
- uPower Firmware.
- Edgelock secure enclave Firmware (ELE).
- uPower Firmware.(8ULP)

- Dualboot mode / Singleboot mode
- U-Boot proper and SPL.
Expand Down Expand Up @@ -59,7 +59,7 @@ by your target:
ARM architecture -> Support i.MX 8 AHAB features

Enabling this feature allows the SPL and uboot image to extend the Root of
Trust by using the AHAB API call via ELke FW.
Trust by using the AHAB API call via ELE FW.

1.3 Building an image supporting secure boot
------------------------------------------------
Expand All @@ -76,12 +76,12 @@ A typical singleboot mode image with Cortex-M support contains three containers:
| and signature | |
+---------------------------+ |
| Padding | | Authenticated at
+---------------------------+ | ELke ROM/FW Level
| ELke FW | |
+---------------------------+ | ELE ROM/FW Level
| ELE FW | |
+---------------------------+ |
| Padding | |
+---------------------------+ |
| uPower FW | |
| uPower FW (8ULP) | |
+---------------------------+ |
| Cortex-M Image | |
+---------------------------+ |
Expand All @@ -97,15 +97,15 @@ A typical singleboot mode image with Cortex-M support contains three containers:
| ARM Trusted FW (ATF) | v
+---------------------------+ ---------

The first container includes the ELke FW which is signed using NXP keys, this
container is authenticated by ELke ROM.
The first container includes the ELE FW which is signed using NXP keys, this
container is authenticated by ELE ROM.

The second container includes the SPL (in dualboot mode) or SPL and uPower FW
(in singleboot mode) which are signed using OEM keys, this container is
authenticated at ELke FW level.
The second container includes the SPL (in dualboot mode) or SPL and uPower FW
(8ULP) (in singleboot mode) which are signed using OEM keys, this container is
authenticated at ELE FW level.

The third container includes the U-Boot proper and the ATF. The SPL is in
charge to load this container and also to interface with ELke FW to authenticate
charge to load this container and also to interface with ELE FW to authenticate
the additional container.

The signing procedure is slightly different when compared with HABv4 series. On
Expand Down Expand Up @@ -171,8 +171,9 @@ In the following sections building and signing a Cortex-A and Cortex-M image is

The boot modes that target Cortex-A core (dualboot and singleboot modes) also
build the uboot and ATF container called "u-boot-atf-container". Please refer
to "soc.mk" file in "<imx-mkimage>/iMX8ULP" for more details. This container is
needed to be signed first before signing the SPL container.
to "soc.mk" file in imx-mkimage repository (for ex: "<imx-mkimage>/iMX8ULP")
for more details. This container is needed to be signed first before signing
the SPL container.

1.4.1.1 Preparing the u-boot-atf-container
-----------------------------------------
Expand Down Expand Up @@ -284,17 +285,16 @@ the device.
---------------------------------------

The boot modes that target Cortex-M core (dualboot and LPboot modes) have one
container to sign which contains the Cortex-M image along with uPower FW.
Please refer to "soc.mk" file in "<imx-mkimage>/iMX8ULP" directory for more
details.
container to sign which contains the Cortex-M image along with uPower FW (8ULP).
Please refer to "soc.mk" file in imx-mkimage repository for more details.

1.4.2.1 Preparing the Cortex-M core image
------------------------------------------

The final flash.bin image created using the imx-mkimage tool contains 2
containers. 1st container consists of the NXP signed ELke FW and thus doesnt
need signing. The 2nd container consists of the Cortex-M image and uPower FW at
the minimum.
containers. 1st container consists of the NXP signed ELE FW and thus doesnt
need signing. The 2nd container consists of the Cortex-M image and uPower FW
(8ULP) at the minimum.

- Generating the flash.bin image:

Expand All @@ -310,8 +310,8 @@ Keep a note of the offsets above to be used with CST/CSF.

Note: The flash.bin image created for Cortex-M core targetting FlexSPI NOR
flash has the 1st container at an offset of 0x1000. This offset can be found in
"soc.mk" file in "<imx-mkimage>/iMX8ULP" directory. Thus the offsets provided
by mkimage tool need to have 0x1000 added to them.
"soc.mk" file in imx-mkimage repository. Thus the offsets provided by mkimage
tool need to have 0x1000 added to them.

1.4.2.2 Signing the Cortex-M core flash.bin image
--------------------------------------------------
Expand Down Expand Up @@ -365,15 +365,13 @@ The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs.

- Dump SRK Hash fuses values in host machine:

On i.MX8ULP, the SRK Hash uses sha256 and dump 8 words fuses
On i.MX8ULP/9x family, the SRK Hash uses sha256 and dump 8 words fuses
$ od -t x4 SRK_1_2_3_4_fuse.bin
0000000 db2959f2 90dfc39c 53394566 e0b75829
0000020 85e6f3b1 af00983d e5e804fe 7a451024

- Program SRK_HASH[255:0] fuses:

* On i.MX 8 ULP:

=> fuse prog 15 0 0xdb2959f2
=> fuse prog 15 1 0x90dfc39c
=> fuse prog 15 2 0x53394566
Expand All @@ -393,25 +391,26 @@ U-Boot terminal.
No events should be returned after this command:

=> ahab_status
Lifecycle: 0x0020, NXP closed
Lifecycle: 0x00000008, OEM Open

No Events Found!

1.8 Close the device
---------------------

After the device successfully boots a signed image without generating any AHAB
security events, it is safe to close the device. The chip lifecycle should be
changed from 0x20 NXP closed to 0x80 OEM closed. Be aware this step can damage
your board if a previous step failed. It is also irreversible. Run on the
U-Boot terminal:
changed from OEM open to OEM closed. Be aware this step can damage your board if
a previous step failed. It is also irreversible. Run on the U-Boot terminal:

=> ahab_close

Now reboot the target, and run:

=> ahab_status
Lifecycle: 0x00000020, OEM Closed

The lifecycle value should now be 0x80 OEM closed.
No Events Found!

2. Authenticating the OS container
-----------------------------------
Expand Down
4 changes: 2 additions & 2 deletions doc/imx/ahab/guides/sign_os_cntr.txt
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
+=========================================================+
+ i.MX 8/8x/8ULP Extend RoT guide using AHAB +
+ Extend RoT guide using AHAB +
+=========================================================+

1. Extension of Root of Trust
Expand Down Expand Up @@ -88,7 +88,7 @@ Finally:

$ sudo umount partition

- For i.MX 8ULP
- For i.MX 8ULP/9x

Goto fastboot mode from uboot:

Expand Down
71 changes: 57 additions & 14 deletions doc/imx/ahab/introduction_ahab.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,10 @@
1. Introduction
----------------

The i.MX 8/8x/8ULP family of applications processors introduce a new secure
The i.MX 8/8x/8ULP/9x family of applications processors introduce a new secure
boot concept. Due to the multi-core architecture, the Security Controller (SECO)
and System Control Unit (SCU) in i.MX 8/8x, and Edgelock secure enclave in i.MX
8ULP are heavily involved in the secure boot process.
and System Control Unit (SCU) in i.MX 8/8x, and Edgelock secure enclave (ELE)
in i.MX 8ULP/9x are heavily involved in the secure boot process.

Step-by-step guides are available under doc/imx/hab/ahab/guides/ directory,
users familiar with AHAB architecture and CST PKI tree generation should
Expand Down Expand Up @@ -71,7 +71,7 @@ available in the Linux BSP Release Notes.
Details about SECO can be found in the processors Security Reference Manual
(SRM).

1.1.3 [i.MX 8ULP] The Edgelock secure enclave
1.1.3 [i.MX 8ULP/9x] The Edgelock secure enclave
-------------------------------------

EdgeLock™ Secure Enclave is the security subsystem based on a dedicated core
Expand All @@ -92,7 +92,7 @@ this FW are available in the Linux BSP Release Notes.
Details about Edgelock secure enclave can be found in the processors Security
Reference Manual (SRM).

NOTE: The terms Sentinel, S400, and EdgeLock secure enclave (ELke), and ELke
NOTE: The terms Sentinel, S400, and EdgeLock secure enclave (ELE), and ELE
are used interchangeably throughout the document.

1.2 The image container
Expand All @@ -103,7 +103,7 @@ boot AHAB supporting devices. In order to store all the images in a single
binary the container image structure is used.

At least two containers are needed for the boot process, the first container
must include only the Security Subsystem FW (SECO/ELke FW provided by NXP).
must include only the Security Subsystem FW (SECO/ELE FW provided by NXP).
Additional containers can contain one or multiple images, depending on the
users specific application.

Expand Down Expand Up @@ -194,18 +194,18 @@ The sequence below explains the i.MX8 and i.MX8x boot flow:
or the U-Boot proper and ATF. Details about current U-Boot implementation
can be found in AHAB guides included in doc/imx/hab/ahab/guides/ directory.

1.4 The i.MX 8ULP secure boot flow
1.4 The i.MX 8ULP/9x secure boot flow
----------------------------------

i.MX8ULP boot sequence involves multiple cores booting up at same time and
The secure boot sequence involves multiple cores booting up at same time and
Edgelock secure enclave ensure authentication of any boot software being loaded.

The diagram below illustrate the secure boot flow overview for dual boot
scenario:
scenario in i.MX 8ULP:


Cortex-M(CM) │ Edgelock Secure │ Cortex-A(CA) │ uPower(uP)
│ Enclave(ELke) │ │
│ Enclave(ELE) │ │
│ │ │ │ │ │ │
┌┬─────┴─────┬┐ │ ┌┬─────┴─────┬┐ │ │ │ ┌┬─────┴─────┬┐
││ INIT ││ │ ││ INIT ││ │ │ │ ││ INIT ││
Expand All @@ -224,10 +224,10 @@ scenario:
├─────────────>├│Auth CM FW ││ ││ ┌┬─────┴─────┬┐ │
│ │ └┴─────┬─────┴┘ ││ ││Start CA FW││ │
┌┬─────┴─────┬┐ │ │ ││ └┴─────┬─────┴┘ │
││Load ELkeFW││ │ │ ││ │ │
││Load ELE FW││ │ │ ││ │ │
└┴─────┬─────┴┘ │ │ ││ │ │
│ │ ┌┬─────┴─────┬┐ ││ │ │
├─────────────>├│Auth ELkeFW││ ││ │ │
├─────────────>├│Auth ELE FW││ ││ │ │
│ │ └┴─────┬─────┴┘ ││ ┌┬─────┴─────┬┐ │
┌┬─────┴─────┬┐ │ │ ││ ││ Load SPL ││ │
││Start CM FW││ │ │ ││ └┴─────┬─────┴┘ │
Expand All @@ -245,9 +245,52 @@ scenario:
│ │ │ │ ││ Run SPL ││ │
│ │ │ │ └┴───────────┴┘ │


The diagram below illustrate the secure boot flow overview for single boot
scenario in i.MX 9x:


Cortex-A(CA) │ Edgelock Secure │ Cortex-M(CM)
│ Enclave(ELE) │
│ │ │ │ │
┌┬─────┴─────┬┐ │ ┌┬─────┴─────┬┐ │ │
││ INIT ││ │ ││ INIT ││ │ │
└┴─────┬─────┴┘ │ └┴─────┬─────┴┘ │ │
│ │ │ │ ┌┬─────┴─────┬┐
│ │ │ │┌>││ INIT ││
│ │ │ ││ └┴─────┬─────┴┘
┌┬─────┴─────┬┐ │ │ ││ |
││Load ELE FW││─────────────>│ ││ │
└┴─────┬─────┴┘ | | |│ |
│ │ ┌┬─────┴─────┬┐ ││ ┌┬─────┴─────┬┐
│ │ ├│Auth ELE FW││ ││ ││Start CM FW││
│ │ └┴─────┬─────┴┘ ││ └┴─────┬─────┴┘
| | | |│ |
┌┬─────┴─────┬┐ │ │ ││ │
││Load CM FW││ │ | ││ │
└┴─────┬─────┴┘ │ │ ││ │
│ │ ┌┬─────┴─────┬┐ ││ │
├─────────────>├│Auth CM FW ││ ││ │
│ │ └┴─────┬─────┴┘ ││ │
| │ │ ││ │
│ │ |───────────┘ │
┌┬─────┴─────┬┐ │ │ │ │
││Load CA FW││ │ │ │ │
└┴─────┬─────┴┘ │ │ │ │
│ │ ┌┬─────┴─────┬┐ │ │
├─────────────>├│Auth CA FW││ │ │
│ │ └┴─────┬─────┴┘ │ │
┌┬─────┴─────┬┐ │ │ │ │
││Start CA FW││ │ | │ │
└┴─────┬─────┴┘ │ │ │ │
| │ │ │ │
| │ │ │ │
| │ │ │ │

More details on the boot flow can be found in respective Security Reference
Manual (SRM).


2. Generating a PKI tree
-------------------------

Expand Down Expand Up @@ -337,7 +380,7 @@ The next step is to generated the SRK Table and its respective SRK Table Hash
from the SRK public key certificates created in one of the steps above.

In the AHAB architecture, the SRK Table is included in the signed image and the
SRK Hash is programmed in the SoC SRK_HASH[511:0] fuses.
SRK Hash is programmed in the SoC SRK_HASH[511:0]/SRK_HASH[255:0] fuses.

On the target device during the authentication process the AHAB code verify the
SRK Table against the SoC SRK_HASH fuses, in case the verification is successful
Expand All @@ -357,7 +400,7 @@ Table Hash.
SRK3_sha384_secp384r1_v3_usr_crt.pem,\
SRK4_sha384_secp384r1_v3_usr_crt.pem

- In i.MX 8ULP, the expected SRK HASH is of 256 bit.
- In i.MX 8ULP/9x, the expected SRK HASH is of 256 bit.
$ cd ../crts/
$ ../linux64/bin/srktool -a -d sha256 -s sha384 -t SRK_1_2_3_4_table.bin \
-e SRK_1_2_3_4_fuse.bin -f 1 -c \
Expand Down

0 comments on commit 97054dd

Please sign in to comment.