CWE-1476
Weakness AllowedImproper Request Propagation before Data Reception in Write Transactions in a Bus Architecture
Abstraction: Base · Status: Incomplete
The product uses a multi-manager shared bus architecture with an on-chip interconnect that speculatively propagates a request for a write transaction, but it does not ensure that the remaining steps required by the manager module to complete the request are fulfilled in a timely manner.
Technical nuance
Here, the word "speculatively" refers to the fact that the interconnect propagates the request assuming that the manager will at some point provide the data, thus releasing the use of the bus.
Mapping guidance
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.
Relationships and members
Modes of introduction
This occurs if the on-chip communication interconnect is based on a multi-channel on-chip communication standard assuming cooperative behavior among the manager modules AND an unsafe switching methodology (e.g., cut-through) is in use. Some switching methodologies may be susceptible to this weakness in modern on-chip multi-channel communication standards, such as the cut-through switching policy, a switching methodology for high performance commonly implemented at the interconnect level. In cut-through, a request is propagated independently on the receipt at the interconnect level of the corresponding data. If the manager module issuing a write request delays the provisioning of the corresponding data, the other manager modules experience delays in accessing the bus. Such delays are capable of generating denial of service.
Detection methods
Architecture or Design Review
Instances of this issue can be detected by manual review of the switching policy implemented in the interconnect and the deployed on-chip communication standard.
Effectiveness: Opportunistic
Manual review requires to have a full description of the architecture of the interconnect. This information might not be available when a third-party interconnect is used.
Formal Verification
Instances of this issue can be found in manager modules by using property-based verification specifically targeting the detection of stalls propagated to the shared resources [REF-1588].
Effectiveness: High
Simulation / Emulation
Instances of this issue can be found in simulation by synthetically generating stalls at the input of the interconnect and evaluating if the interconnect propagates the stalls at the output or not.
Effectiveness: Moderate
Simulations should be capable of triggering the stalls. Not all of the Verification IP for on-chip communications might be capable of triggering this issue.
Content history
0 vulnerabilities reference this CWE, most recent first.
No vulnerabilities reference this CWE.
Mitigation
SoC architects can use a switching methodology stopping stalls from being propagated to the interconnect, such as Cut-and-Forward [REF-1585][REF-1587] or Store-and-Forward. Alternatively, a monitoring and recovery module can be added between the interconnect and each manager module to detect stalls introduced by the module and restore a safe state in the interconnect after a stall has been detected [REF-1586].
No CAPEC attack patterns related to this CWE.