Hello
I am working on HAB secure boot. We can boot secure from NAND and MMC using boards in open and closed configuration.
However I have not managed to boot via freescale manufacturing tools without HAB events.
If we boot a 'normal' singed u-boot.bin via MFG tool, we get ~5 HAB events.
If we use the scripts from AN4581 6.2, I still get one single HAB event.
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00
0x00 0x00 0x02 0x88
STS: 0x33 RSN: 0x0c CTX: 0xa0 ENG: 0x00
Does anyone have experience with secure serial boot?
What irritates me, is that we had to remove the coma / logical line break from the sample cst code in AN4581. The sample in AN 4581 generates a syntax error.
[Authenticate Data]
Verification index = 2
Blocks = 0x10800400 0x400 0x2BC00 "u-boot-pad.bin", \
Blocks = 0x00910000 0x430 0x2E0 "u-boot-pad.bin"
How do I get rid of that HAB event?
Regards,
Martin
Solved! Go to Solution.
1.
As I know the problem was solved :
From AN 4581:
--
[Authenticate Data]
Verification index = 2
Blocks = 0x10800400 0x400 0x2BC00 "u-boot-pad.bin", \ Blocks = 0x00910000 0x430 0x2E0 "u-boot-pad.bin"
--
This generates a syntax error
We used:
--
[Authenticate Data]
Verification index = 2
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
--
This generates a HAB assert at 0x00910000
--
[Authenticate Data]
Verification index = 2
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
--
Generates 3 HAB assertions in DRAM
--
[Authenticate Data]
Verification index = 2
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
[Authenticate Data]
Verification index = 2
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
--
This works.
2.
As for the HAB Event below :
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00
0x00 0x00 0x02 0x88
STS: 0x33 RSN: 0x0c CTX: 0xa0 ENG: 0x00
Header Word: 0xdb 0x00 0x14 0x41
Tag = 0xDB Event
Length = 0x0014 Length of event record in bytes
Version: 0x41 HAB Version
SRCE Word: 0x33 0x0c 0xa0 0x00
Status = 0x33 HAB_FAILURE
Reason = 0x0c HAB_INV_ASSERTION
Context = 0xa0 HAB_CTX_AUTHENTICATE
Engine = 0x00 HAB_ENG_ANY
Event Data: Since the Context is HAB_CTX_AUTHENTICATE the reason must also be
taken into account.
Here the reason is HAB_INV_ASSERTION so the context dependent data in this
example corresponds to HAB_CTX_ASSERT which contains the hab_rvt.assert() call
parameters in the order they appear in the parameter list.
type: 0x00 0x00 0x00 0x00 = HAB_ASSERT_BLOCK
0x00 0x91 0x00 0x00 = data address
0x00 0x00 0x02 0x88 = data length in bytes
Note, that the API checks that all of the following data have been authenticated
(using their final locations):
IVT
DCD (if provided);
Boot Data (initial byte if provided);
Entry point (initial word).
Each of the above data components not covered by a valid signature will cause
HAB to generate an event with reason HAB_INV_ASSERTION like the one above.
Hello Martin,sorry to bother u.but hope you can do me a favor with "Signing Code Downloadable with Manufacturing Tool".
I've done as the AN4581 says.but i met HAB Event unfortunately.witch as follow.
Out: serial
Err: serial
Checking HAB_status
HAB Configuration: 0xf0 HAB State: 0x66
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00
--------- HAB Event 2 -----------------
event data:
0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00
--------- HAB Event 3 -----------------
event data:
0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00
--------- HAB Event 4 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x07 0x00
0x00 0x00 0x00 0x20
--------- HAB Event 5 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x07 0x20
0x00 0x00 0x00 0x04
--------- HAB Event 6 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00
0x00 0x00 0x02 0xe0
Net: got MAC address from IIM: 00:01:02:03:04:05
FEC0 [PRIME]
..main_loop
------------------------------------------------------------------------------------------------------
My u-boot.csf file comes bellow:
-----------------------------------------------------------------------------------------------------
[Header]
Version = 4.0
Security Configuration = Open
Hash Algorithm = sha256
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS
[Install SRK]
File = "../crts/SRK_1_2_3_4_table.bin"
Source index = 0
[Install CSFK]
File = "../crts/CSF1_1_sha256_1024_65537_v3_usr_crt.pem"
[Authenticate CSF]
[Install Key]
Verification index = 0
Target index = 2
File = "../crts/IMG1_1_sha256_1024_65537_v3_usr_crt.pem"
# Sign padded u-boot starting at the IVT through to the end with
# length = 0x2F000 (padded u-boot length) - 0x400 (IVT offset) = 0x2EC00
# Note: 0x2F000 may be different depending on the size of U-Boot
# This covers the essential parts: IVT, boot data and DCD.
# Blocks have the following definition:
# Image block start address on i.MX, Offset from start of image file,
# Length of block in bytes, image data file
[Authenticate Data]
Verification index = 2
Blocks = 0x27800400 0x400 0x2EC00 "u-boot-pad.bin",\
0x00910000 0x42C 0x2E0 "u-boot-pad.bin"
---------------------------------------------------------------------------------------------------
The pic above is the IVT get from u-boot-signed-pad.bin.
--------------------------------------------------------------------------------------------------
Can u help me with this.TKS.
1.
As I know the problem was solved :
From AN 4581:
--
[Authenticate Data]
Verification index = 2
Blocks = 0x10800400 0x400 0x2BC00 "u-boot-pad.bin", \ Blocks = 0x00910000 0x430 0x2E0 "u-boot-pad.bin"
--
This generates a syntax error
We used:
--
[Authenticate Data]
Verification index = 2
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
--
This generates a HAB assert at 0x00910000
--
[Authenticate Data]
Verification index = 2
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
--
Generates 3 HAB assertions in DRAM
--
[Authenticate Data]
Verification index = 2
Blocks = 0x00910000 0x42c 0x288 "u-boot-pad.bin"
[Authenticate Data]
Verification index = 2
Blocks = 0x27800400 0x400 0x3BC00 "u-boot-pad.bin"
--
This works.
2.
As for the HAB Event below :
--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00
0x00 0x00 0x02 0x88
STS: 0x33 RSN: 0x0c CTX: 0xa0 ENG: 0x00
Header Word: 0xdb 0x00 0x14 0x41
Tag = 0xDB Event
Length = 0x0014 Length of event record in bytes
Version: 0x41 HAB Version
SRCE Word: 0x33 0x0c 0xa0 0x00
Status = 0x33 HAB_FAILURE
Reason = 0x0c HAB_INV_ASSERTION
Context = 0xa0 HAB_CTX_AUTHENTICATE
Engine = 0x00 HAB_ENG_ANY
Event Data: Since the Context is HAB_CTX_AUTHENTICATE the reason must also be
taken into account.
Here the reason is HAB_INV_ASSERTION so the context dependent data in this
example corresponds to HAB_CTX_ASSERT which contains the hab_rvt.assert() call
parameters in the order they appear in the parameter list.
type: 0x00 0x00 0x00 0x00 = HAB_ASSERT_BLOCK
0x00 0x91 0x00 0x00 = data address
0x00 0x00 0x02 0x88 = data length in bytes
Note, that the API checks that all of the following data have been authenticated
(using their final locations):
IVT
DCD (if provided);
Boot Data (initial byte if provided);
Entry point (initial word).
Each of the above data components not covered by a valid signature will cause
HAB to generate an event with reason HAB_INV_ASSERTION like the one above.