Trace data collected from several sources on the
System-on-Chip (SoC) is stored in unprotected locations or
transported to untrusted agents.

To facilitate verification of complex System-on-Chip
(SoC) designs, SoC integrators add specific IP blocks that
trace the SoC's internal signals in real-time. This
infrastructure enables observability of the SoC's internal
behavior, validation of its functional design,
and detection of hardware and software bugs. Such tracing
IP blocks collect traces from several sources on the SoC
including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then
aggregated inside trace IP block and forwarded to trace
sinks, such as debug-trace ports that facilitate debugging by
external hardware and software debuggers.
Since
these traces are collected from several security-sensitive
sources, they must be protected against untrusted
debuggers. If they are stored in unprotected memory, an
untrusted software debugger can access these traces and
extract secret information. Additionally, if
security-sensitive traces are not tagged as secure, an
untrusted hardware debugger might access them to extract
confidential information.

Primary

Resultant

Architecture and Design

Implementation

Confidentiality
Read Memory
An adversary can read secret values if they are captured in debug traces and stored unsafely.

Implementation
Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.

In a SoC, traces generated from sources
include security-sensitive IP blocks such as CPU (with
tracing information such as instructions executed and
memory operands), on-chip fabric (e.g., memory-transfer
signals, transaction type and destination, and
on-chip-firewall-error signals), power-management
IP blocks (e.g., clock- and power-gating signals), and
cryptographic coprocessors (e.g., cryptographic keys and
intermediate values of crypto operations), among
other non-security-sensitive IP blocks including timers
and other functional blocks. The collected traces are
then forwarded to the debug and trace interface used by
the external hardware debugger.
The traces do
not have any privilege level attached to them. All
collected traces can be viewed by any debugger (i.e., SoC
designer, OEM debugger, or end user).
Some of the
traces are SoC-design-house secrets, while some are OEM
secrets. Few are end-user secrets and the rest are
not security-sensitive. Tag all traces with the
appropriate, privilege level at the source. The bits
indicating the privilege level must be immutable in
their transit from trace source to the final, trace
sink. Debugger privilege level must be checked before
providing access to traces.

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Hareesh Khattri, Parbati K. Manna, and Arun Kanuparthi
Intel Corporation
2020-07-20
4.3
2020-12-10

CWE Content Team
MITRE
2021-10-28
updated Common_Consequences

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities