CWE-1429: Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface

Description:
The product has a hardware interface that silently discards operations
			in situations for which feedback would be security-relevant, such as
			the timely detection of failures or attacks.

Extended Description:
While some systems intentionally withhold feedback as a security
			  measure, this approach must be strictly controlled to ensure it does
			  not obscure operational failures that require prompt detection and
			  remediation.  Without these essential confirmations, failures go
			  undetected, increasing the risk of data loss, security
			  vulnerabilities, and overall system instability. Even when withholding
			  feedback is an intentional part of a security policy designed, for
			  example, to prevent attackers from gleaning sensitive internal
			  details, the absence of expected feedback becomes a critical weakness
			  when it masks operational failures that require prompt detection and
			  remediation. 
			   For instance, certain encryption algorithms always return ciphertext
			  regardless of errors to prevent attackers from gaining insight into
			  internal state details. However, if such an algorithm fails to
			  generate the expected ciphertext and provides no error

Affected languages: C, C++, Verilog, Hardware Description Language, Not Language-Specific
Affected technologies: Security Hardware, Processor Hardware, Microcontroller Hardware, System on Chip
Parent weaknesses: CWE-223

Consequences:
  - Confidentiality: Read Memory
  - Integrity: Modify Memory
  - Availability: DoS: Resource Consumption (Memory)

Detection methods:
  - Automated Static Analysis - Source Code: Scans code for missing error handling or feedback mechanisms.
  - Manual Static Analysis - Source Code: Experts manually inspect the code for unhandled operations.

Mitigations:
  - [Architecture and Design] Incorporate logging and feedback mechanisms during the
				design phase to ensure proper handling of discarded operations.
  - [Implementation] Developers should ensure that every critical operation
				includes proper logging or error feedback mechanisms.

Demonstrative examples:
This code creates an interrupt handler.  If the interrupt's priority
is lower than the currently active one, the interrupt is discarded
without any feedback, perhaps due to resource constraints.
The omission of feedback for the dropped lower-priority interrupt can
					cause developers to misinterpret the state of the system, leading to
					incorrect assumptions and potential system failures, such as missed
					sensor readings. 
					 Attackers might leverage this lack of visibility to induce conditions
					that lead to timing side-channels. For example, an attacker could
					intentionally flood the system with high-priority interrupts, forcing
					the system to discard lower-priority interrupts consistently. If these
					discarded interrupts correspond to processes executing critica

Consider a SoC design with these component IPs: 
				   IP 1. Execution Core  <--> IP 2 SoC Fabric (NoC, tile etc. )  <--> IP 3 Memory Controller  <--> External/ internal memory. 
				   The Core executes operations that trigger transactions that traverse
				  the HW fabric links to read/write to the final memory module. 
				   There can be unexpected errors in each link. For adding reliability
				  and redundance, features like ECCs are used in these
				  transactions. Error correction capabilities have to define how many
				  error bits can be detected and which errors can be corrected, and
				  which are uncorrectable errors. In design, often the severity level
				  and response on different errors is allowed to be configured by system
				  firmware modules like BIOS.
For system

Real-world examples:
  - [REF-1468]: Open source silicon root of trust (RoT) product does not immediately report when an integrity check fails for memory requests, causing the product to accept and continue processing data [REF-1468]