Hello everybody,
I made an attempt to set one of the unlocked teensy boards to closed configuration after having burnt the SRK hash fuses and successful HAB authentication in open configuration. But rather undexpectedly the board didn't answer anymore after reset. After long second thought what mistake I might have made and what I should do different, I decided to do the same steps at my MIMXRT1060-EVK with the difference that on this board I'm able to get into the running software via JTAG Debugger. So the result was quite similar right after programming the signed bootloader image via debugger. Anyway, I was still able to debug the code an step/jump arround and inspect memories and registers. First idea was to check the watchdogs and indeed they where enabled. Later it turned out, that this is the proper behaviour and when the image gets authenticated successfully, they are turned off by the HAB before the image starts to execute.
Somhow I managed to send a command via UART into my bootloader to evaluate and dump the HAB status and this is what I got:
Code:
Hello FBL
FBL>habStatus
HAB Configuration: 0xcc (closed) HAB State: 0x66 (non-secure)
----- HAB Event 1 -----
Event Data:
0xDB 0x00 0x2C 0x43
0x33 0x30 0xE1 0x1E
0x00 0x00 0x00 0x00
0x80 0x00 0xBB 0x00
0x80 0x00 0x00 0x02
0x00 0x00 0x00 0x20
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x08
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
Tag: 0xDB -> EVT
Len: 0x002C -> 44 Bytes
Par: 0x43 -> HAB Ver: 4.3
Evt Status: 0x33 -> HAB_FAILED
Evt Reason: 0x30 -> ENGINE_FAIL
Evt Context: 0xE1 -> ENTRY
Evt Engine: 0x1E -> SNVS
----- HAB Event 2 -----
Event Data:
0xDB 0x00 0x2C 0x43
0x33 0x30 0xE1 0x1E
0x00 0x00 0x00 0x00
0x80 0x00 0xBB 0x00
0x80 0x00 0x00 0x02
0x00 0x00 0x00 0x20
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x08
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
Tag: 0xDB -> EVT
Len: 0x002C -> 44 Bytes
Par: 0x43 -> HAB Ver: 4.3
Evt Status: 0x33 -> HAB_FAILED
Evt Reason: 0x30 -> ENGINE_FAIL
Evt Context: 0xE1 -> ENTRY
Evt Engine: 0x1E -> SNVS
No more HAB Events found!
According to High Assurance Boot Version 4 Application Programming Interface Reference Manual, Page 57, the 3rd to last line of the hex dump of the events show the following SNVS registers:
If an entry, exit or test operation fails, an audit event is logged with status field HAB_FAILURE, reason field HAB_ENG_FAIL, engine field HAB_ENG_SNVS and data field containing the following registers (in order):
o HP Security Violation Control
o HP Status
o HP Security Violation Status
o LP Control
o LP Master Key Control
o LP Security Violation Control
o LP Status
o LP Secure Real Time Counter MSB
o LP Secure Real Time Counter LSB
Inspecting the very same registers via JTAG debugger shows like the hex dump, that the HP Security Violation Status Register (HPSVSR) has Security Violation 1 set, which according to Security Reference Manual for the i.MX RT1050 Processor, Rev. 1, 04/2018, Page 50 is linked to SJC JTAG active. Obviously this security violation cannot be disabled, just configured as fatal or non-fatal violation.
Later I did a power-on reset on the EVK and I was very surprised to see the proper prompt of the bootloader image on the terminal. So what happened? By powering off the board, the JTAG connection was killed and the HAB obviously successfully authenticated the bootloader image. Experimenting with the running image confirmed the suspicion that a connected JTAG might be the reason for the failed authentiation. Here is the HAB status after power-on reset (1) and after re-attaching the JTAG debugger on the EVK board:
Code:
Hello FBL
FBL>boot
Enter FBL
FBL>habCheck
ROM-Boot ok.
FBL>habStatus
HAB Configuration: 0xcc (closed) HAB State: 0x99 (trusted)
No HAB Events Found!
Code:
FBL>habStatus
HAB Configuration: 0xcc (closed) HAB State: 0xcc (fail_soft)
No HAB Events Found!
As you can see, after attaching the JTAG debugger, the HAB state changes from "trusted" to "fail_soft" and this is a reproducable issue.
So my assumption for the teensy now is, that due to the JTAG access by the MKL02 chip the SNVS asserts a security violation already while the ROM bootloader is running and so the HAB fails due to security checks as seen in the very first terminal output.
What can be seen on the teensy is, that the Halfkay injecttion via JTAG is still working. So when I shortly press the push button, I'm able to program another image, but obviously this doesn't run because of the reboot following the reprogramming. Also due to the failed HAB authentication the teensy switches to serial download mode, which might be a last resort to un-brick this board. Until now I was not able to get any useful information out of the "bricked" teensys by the sdphost tool as it repeatedly answers with status "HAB enabled" and no reasonable value returned.
So I'm writing this here the in order to possibly get some confirmation or feedback for my assumptions befor I may brick another unlocked teensy in the attempt to disable JTAG access before setting it to closed configuration. Especially I'd like to get confirmed, that the MKL02 chip is connecting to the IMXRT on every reset, not just after pressing the push button, which would further proof the assumption that the reason for the failed authentication is the JTAG connection.
A question here is, if there is a way to temporarily prevent the MKL02 to JTAG the IMXRT after reset. A further question is whether the MKL02 will still apply the necessary signals to let the IMXRT run, if the JTAG connection doesn't due to disablement. A 3rd question is, whether there is a way to tell the Halfkay to directly jump to an address instead of resetting the chip, when it has programmed an image.
Does anybody know how to prevent HAB checking the SNVS status registers or disable SNVS during boot? The latter is implied in a note in the HABv4 API RM:
Note: If a failure occurs when the SNVS is not enabled then the audit event reason field is HAB_WARNING rather than HAB_FAILURE.