Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Caliptra transition to the DebugUnlocked whenever the SoC enters the debug state, regardless of the product lifecycle state? #252

Open
coach-bin opened this issue Dec 13, 2024 · 0 comments

Comments

@coach-bin
Copy link

coach-bin commented Dec 13, 2024

Hi,

According to the Caliptra spec, when the SoC enters the debug state, Caliptra must also transition to an unsecured state (presumably DebugUnlocked). However, I wonder if "insecure state" might be a more accurate term than "debug state."

https://github.com/chipsalliance/Caliptra/blob/main/doc/caliptra_1x/Caliptra.md#caliptra-security-states
SoC’s requirement is that if the SoC enters a debug state, then Caliptra must also be in an unsecured state where all assets are cleared.

In general, during the manufacturing phase of a device, full debugging capabilities are typically required, and pre-shipment tests should align with the functionality of the product as it will be used in the field. At this stage, however, does it make sense to define the SoC as being in the debug state and to set Caliptra to DebugUnlocked? This approach feels somewhat unnatural, especially considering that UDS and other conditions might differ from the actual product's behavior.

From another perspective, it’s also unclear whether all debugging capabilities(e.g. JTAG) of the SoC must be disabled to align with Caliptra's DebugLocked state during the device manufacturing phase. If the SoC can be considered to be in a secure state rather than a debug state during the Device Manufacturing stage, concerns about debug state synchronization would no longer apply. However, the meaning and scope of the term "debug state" seem very ambiguous.

From my understanding,...

  • Unprovisioned state is don't care. Because it has only one state.
  • Manufacturing state assumes that the provisioner is in a secure state (e.g., secure HVM) and that Caliptra is in DebugLocked by default, with a transition to DebugUnlocked possible only through a warm reset (please correct if I'm wrong). However, it is unclear whether SoC JTAG debugging is allowed in this stage.(Manufacturing/DebugLocked) (This is the part that I'd like to see clarified)

Manufacturing -> insecure state transition is allowed with warm reset and Caliptra clears all of the security critical assets and registers before JTAG is opened.

  • It is unclear whether SoC JTAG debugging is allowed in Caliptra's Production/DebugLocked state during the device manufacturing stage. And it's unclear if we can assume SoC is in the secure state rather than the debug state in this stage.

It would be need a clarification on 'SoC debug state' in these scenarios. Depending on the definition, 'insecure state' might be more accurate than 'debug state'.

@coach-bin coach-bin changed the title SoC debug state and Caliptra debug state Should Caliptra transition to the DebugUnlocked whenever the SoC enters the debug state, regardless of the product lifecycle state? Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant