JTAG Debugging - Secure JTAG Mode Enabled and Close Configuration

jeremyd · ‎03-19-2018

Hello,

Configuration:
i.MX6DL processor - Close Configuration and Secure JTAG Mode enabled.
All burned fuses: TESTER_LOCK = 11 (OP + WP), BOOT_CFG_LOCK = 10 (OP), SJC_RESP_LOCK = 1, SRK_LOCK = 1, SEC_CONFIG = 1, DIR_BT_DIS = 1, JTAG_SMODE = 01 (Secure JTAG mode), SRK_HASH = production keys’ hash, SJC_RESP = xxx and JTAG_HEO = 1

In this configuration our software is running OK, however as soon as we attach our debugger during runtime (Lauterbach Power Debug) successfully according to AN4686 (using DO imx6_attach_secured.cmm ENRESET=OFF) our software stops to run.

The analysis of this issue on our side showed that the CAAM Job Ring 0 Interrupt is constantly triggered after successful attachment. Please note that our software uses the CAAM module and enable these interrupts during start-up. Moreover, clearing (w1c) the JRI bit (JRINTR register) during the execution of the ISR seems to not have effect as shown in the attached picture.

Last observation, the Security Reference manual mentions under "Scan protection":

"The chip includes further scan protection logic for SJC modes where JTAG use is
allowed. This ensures that access to critical security values is protected as follows.
...
Security modules-including CAAM, SNVS, CSU, and OCOTP_CTRL-have
additional scan protection logic to protect sensitive internal data and functionality.
..."

To summarize:
Board with i.MX6DL – Open Configuration and Secure JTAG mode Disabled => No issue to debug the board, the SW is still running OK
Board with i.MX6DL – Open Configuration and Secure JTAG mode Enabled => No issue to debug the board, the SW is still running OK
Board with i.MX6DL – Close Configuration and Secure JTAG mode Enabled => The SW is not running correctly as soon as the debugger

Thank you for support,
Jeremy

utkarsh_gupta · ‎04-11-2018

Hi Jeremy,

However I have a question, are you using Lauterbach tools as mentioned in the issue description or another debug tool ?

[UG] Yes I am using Lauterbach

Moreover, I have an idea of a scenario that you could perform:
Attach your debug tool to the board (i.MX6Q in a closed configuration) during runtime
Perform a software reset of the i.MX6Q
I know that the JTAG connection will reset but I am interested in knowing if the boot rom code will be able to
properly authenticate your images and start u-boot in your case. I observed that in such scenario the boot rom code fails to authenticate images so it does not jump over our custom boot loader (u-boot in your case).

[UG] Yes that the correct behavior. The Boot ROM does not allow booting a chip with active JTAG connection. It has protection in place (including HAB) that monitors the security violations and does not transition to chip (SSM) from Init to Secure state/Trusted state. Instead, it fails to boot and brings up serial download.

One more point, before to post here I have (wrongly) created a "support case" (#00154424), with more or less the same content that I posted here.

And I got the following answer:
" The behaviour you describe is the expected one for the Closed HAB configuration due to the scan protection logic operation you've mentioned. "

But if you are able to attach and debug in a closed configuration on your side I feel confused.

[UG] It is true that the scan protection logic will not allow debugging of sensitive information that exists in CAAM, SNVS etc modules. Although the interrupt generation right after attaching the debugger seems to be peculiar and is what I am trying to replicate here.

The SNVS log you sent also seems to work correctly, i.e. switching SSM state to Soft fail when JTAG is active.

Is it possible that your code is trying to access certain chip secret information for blob operation or something due to which when you connect to the JTAG, CAAM throws this interrupt?

The interrupt status reports the following:

If reading HALT returns 10: CAAM has flushed all jobs from this Job Ring and has halted processing jobs in this
Job Ring. If there is not enough room in the Output Ring for all the flushed jobs, HALT will continue to return
01 until software has removed enough jobs so that all the flushed jobs can be written to the Output Ring.
Software writes a “1” to the MSB of HALT (bit 3) to clear the HALT field and resume processing jobs in this Job
Ring. An error will occur if 1 is written to the MSB of the HALT field before the HALT field indicates that
CAAM has flushed all jobs from this Job Ring.

Thanks,

Utkarsh

jeremyd · ‎05-02-2018

Hello Utkarsh,

I've added a while loop to our startup code to let me the possibility to debug this issue from the beginning of execution.

I've observed that as soon as the GIC is enabled (0x3 to ICDDCR register), interrupts related to CAAM are set to Pending which is for me suspect.

Before Enabling the GIC:

Right after Enabling the GIC:

This is suspicious for me and I am wondering why it happens since we are at the very beginning of the execution. Can you confirm this behavior on you side ?

Thank you,

Jeremy

jeremyd · ‎04-12-2018

Hello,

Is it possible that your code is trying to access certain chip secret information for blob operation or something due to which when you connect to the JTAG, CAAM throws this interrupt?

[JD] Yes I confirm that it is possible that our code is trying to access certain chip secret information for blob operation.

The interrupt status reports the following:
If reading HALT returns 10: CAAM has flushed all jobs from this Job Ring and has halted processing jobs in this
Job Ring. If there is not enough room in the Output Ring for all the flushed jobs, HALT will continue to return
01 until software has removed enough jobs so that all the flushed jobs can be written to the Output Ring.
Software writes a “1” to the MSB of HALT (bit 3) to clear the HALT field and resume processing jobs in this Job
Ring. An error will occur if 1 is written to the MSB of the HALT field before the HALT field indicates that
CAAM has flushed all jobs from this Job Ring.

[JD] I need to learn more about CAAM to have a clear understanding. So I will continue investigation on my side and come back to you when I will feel more comfortable with this subject.

Thanks,

Jeremy

jeremyd · ‎04-08-2018

Hello Utkarsh,

I've added logs to show the content of all SNVS related registers (before attaching Secure JTAG on a closed board):

<2018-04-09> <08:36:29.477> HPLR 0x020CC000- 0x703FF
<2018-04-09> <08:36:29.478> HPCOMR 0x020CC004- 0x2024
<2018-04-09> <08:36:29.478> HPCR 0x020CC008- 0x0
<2018-04-09> <08:36:29.478> HPSR 0x020CC014- 0x80000F00
<2018-04-09> <08:36:29.479> HPRTCMR 0x020CC024- 0x0
<2018-04-09> <08:36:29.479> HPRTCLR 0x020CC028- 0x0
<2018-04-09> <08:36:29.479> HPTAMR 0x020CC02C- 0x0
<2018-04-09> <08:36:29.479> HPTALR 0x020CC030- 0x0
<2018-04-09> <08:36:29.479> LPLR 0x020CC034- 0x3CB
<2018-04-09> <08:36:29.480> LPCR 0x020CC038- 0x20
<2018-04-09> <08:36:29.480> LPSR 0x020CC04C- 0x80000008
<2018-04-09> <08:36:29.480> LPSMCMR 0x020CC05C- 0x0
<2018-04-09> <08:36:29.480> LPSMCLR 0x020CC060- 0x0
<2018-04-09> <08:36:29.480> LPGPR 0x020CC068- 0x0
<2018-04-09> <08:36:29.480> HPVIDR1 0x020CCBF8- 0x3E0100
<2018-04-09> <08:36:29.481> HPVIDDR2 0x020CCBFC- 0x0

And then I have dumped the memory from 0x020CC000 after I attached Secure JTAG on the same closed board:

Thank you,

Jeremy

jeremyd · ‎04-05-2018

One more point, before to post here I have (wrongly) created a "support case" (#00154424), with more or less the same content that I posted here.

And I got the following answer:

" The behaviour you describe is the expected one for the Closed HAB configuration due to the scan protection logic operation you've mentioned. "

But if you are able to attach and debug in a closed configuration on your side I feel confused.

Jeremy

jeremyd · ‎04-05-2018

Hello Utkarsh,

I've just seen your replies, I am sorry for the delay. To answer your questions:

Yes, I can log/dump SNVS-related registers but it will require a bit of time, hopefully I can provide you these values by tomorrow or next Monday
We are running AUTOSAR (Automotive specific platform) on the core 0 of the i.MX6DL
Clearly, we are not ready to test with the NXP BSP Release at the moment because we were not using it so far and I am not sure how much effort is needed on our side.

However I have a question, are you using Lauterbach tools as mentioned in the issue description or another debug tool ?

Moreover, I have an idea of a scenario that you could perform:

Attach your debug tool to the board (i.MX6Q in a closed configuration) during runtime
Perform a software reset of the i.MX6Q
1. I know that the JTAG connection will reset but I am interested in knowing if the boot rom code will be able to
  properly authenticate your images and start u-boot in your case. I observed that in such scenario the boot rom code fails to authenticate images so it does not jump over our custom boot loader (u-boot in your case).

Thank you and again sorry for the delay,

Jeremy

utkarsh_gupta · ‎03-22-2018

Hi Jeremy,

Which OS are you running ? Can you also try this scenario with NXP BSP release? It would help in replicating the issue.

I tested debugging using JTAG in SecureJTAG more in a closed chip and haven't had issues in debugging the u-boot or kernel code.

Thanks,

Utkarsh

utkarsh_gupta · ‎03-21-2018

Hi Jeremy,

Can you dump the SNVS register values before and after the JTAG is attached and you get the JR interrupt trigger.

Thanks,

Utkarsh

utkarsh_gupta · ‎03-21-2018

Hi Jeremy,

I am currently looking into this issue. I have tried to perform Secure JTAG debug on an MX6Q closed part and haven't had issues. This part is very similar to the i.MX6DL you are using.

Currently, I am trying to replicate the fuse settings you have reported so that we have the same setup to go ahead with. I will respond soon with my findings.

Thanks,

Utkarsh