CWE-1476 Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture

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.

• Availability: DoS: Prevent Access — The technical impact could include Memory-access delays, I/O access delays, deadline miss, etc. The attacker can leverage this weakness to generate unbounded delays and denial of service (DoS) in the access of shared resources. The system interconnect might be left in an inconsistent state, requiring a partial or full reset of the network, according to the implementation. The scenario may play out as follows. The interconnect receives a write request from a controller initiator (e.g., sending the header to the interconnect for writing N words of data, with N ranging from 1 to the maximum burst length allowed). The interconnect then speculatively propagates the request to the target peripheral through the shared bus before the corresponding data are received at the interconnect. Here, the word "speculatively" refers to the fact that the interconnect propagates the request, assuming that the controller will at some point provide the data, thus releasing the use of the bus. This speculatively reserves the bus to the manager transaction issuer, which is left free to delay its data provisioning phase. This reserves the whole bus path between the initiator and the target peripheral until all of the words associated with the request are provided by the controller. If the interconnect assumes a cooperative behavior from the controller, it is implicitly trusting that the controller will complete the transaction and release the bus for use from the other controllers. A malicious, faulty, or misbehaving manager module can generate a denial-of-service condition in preventing access to the write data link from all of the other managers in the system, and unboundedly inhibit the write access to one or multiple peripherals in the system (i.e., memories, I/Os, etc.).

• 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].

• 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. • 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]. • 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.

• [REF-1586]: Certain commercial AXI interconnect IPs could allow a manager to cause bus stalls.