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

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 critical security functions (e.g., cryptographic key handling), an attacker might measure system timing variations to infer when and how those functions are executing. This creates a timing side channel that could be used to extract sensitive information. Moreover, since these lower-priority interrupts are not reported, the system remains unaware that critical tasks such as sensor data collection or maintenance routines, are being starved of execution. Over time, this can lead to functional failures or watchdog time resets in real-time systems. One way to address this problem could be to use structured logging to provide visibility into discarded interrupts. This allows administrators, developers, or other authorized entities to track missed interrupts and optimize the system.

void interrupt_handler(int irq) { 					   						if (irq_priority[irq] < current_priority) { 						 						  return; 						 						} 						process_interrupt(irq); 					   					  }

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 critical security functions (e.g., cryptographic key handling), an attacker might measure system timing variations to infer when and how those functions are executing. This creates a timing side channel that could be used to extract sensitive information. Moreover, since these lower-priority interrupts are not reported, the system remains unaware that critical tasks such as sensor data collection or maintenance routines, are being starved of execution. Over time, this can lead to functional failures or watchdog time resets in real-time systems. One way to address this problem could be to use structured logging to provide visibility into discarded interrupts. This allows administrators, developers, or other authorized entities to track missed interrupts and optimize the system.

// Priority threshold for active interrupts 					  int current_priority = 3; 					  // Simulated priority levels for different IRQs 					  int irq_priority[5] = {1, 2, 3, 4, 5}; 					  void process_interrupt(int irq) { 					   						printf("Processing interrupt %d\n", irq); 					   					  } 					  void interrupt_handler(int irq) { 					   						if (irq_priority[irq] < current_priority) { 						 						  // Log the dropped interrupt using structured feedback 						  fprintf(stderr, "Warning: Interrupt %d dropped (Priority: %d < Current: %d)\n",  						   							irq, irq_priority[irq], current_priority); 						   						  exit(EXIT_FAILURE);  // Exit with failure status to indicate a critical issue. 						 						} 						process_interrupt(irq); 					   					  }

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 security, if an uncorrectable error occurs but is not reported to the execution core and handled before the core attempts to consume the data that is read/written through the corrupted transactions, then this could enable silent data corruption (SDC) attacks. In the case of confidential compute technologies where system firmware is not a trusted component, error handling controls can be misconfigured to trigger this weakness and attack the assets protected by confidential compute.

If an uncorrectable error occurs, the design does not explicitly 					trigger an alert back to the execution core.

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 security, if an uncorrectable error occurs but is not reported to the execution core and handled before the core attempts to consume the data that is read/written through the corrupted transactions, then this could enable silent data corruption (SDC) attacks. In the case of confidential compute technologies where system firmware is not a trusted component, error handling controls can be misconfigured to trigger this weakness and attack the assets protected by confidential compute.

Modify the design so that any uncorrectable error triggers an alert 					back to the execution core and gets handled before the core can 					consume the data read/written through the corrupted transactions. 					Update design access control policies to ensure that alerts sent to 					execution core on uncorrectable errors cannot be disabled or masked by 					untrusted software/firmware.