You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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."
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'.
The text was updated successfully, but these errors were encountered:
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
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."
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,...
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'.
The text was updated successfully, but these errors were encountered: