deardaniel/secdata-raw huggingface dataset:
CWE-1303: Non-Transparent Sharing of Microarchitectural Resources

Description:
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.

Extended Description:
Modern processors use techniques such as out-of-order execution, speculation, prefetching, data forwarding, and caching to increase performance. Details about the implementation of these techniques are hidden from the programmer's view. This is problematic when the hardware implementation of these techniques results in resources being shared across supposedly isolated contexts. Contention for shared resources between different contexts opens covert channels that allow malicious programs executing in one context to recover information from another context. 
				
				 Some examples of shared micro-architectural resources that have been used to leak information between contexts are caches, branch prediction logic, and load or store buffers. Speculative and out-of-order execution provides an attacker with increased control over which data is leaked through the covert channel. 
				
				 If the extent of resource sharing between contexts in the design microarchitecture is undocumented, it i

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-1189, CWE-203

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers.
  - [Requirements] Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers.

Demonstrative examples:
On some processors the hardware indirect branch predictor is shared between execution contexts, for example, between sibling SMT threads. When SMT thread A executes an indirect branch to a target address X, this target may be temporarily stored by the indirect branch predictor. A subsequent indirect branch mis-prediction for SMT thread B could speculatively execute instructions at X (or at a location in B's address space that partially aliases X). Even though the processor rolls back the architectural effects of the mis-predicted indirect branch, the memory accesses alter data cache state, which is not rolled back after the indirect branch is resolved.
CWE-1304: Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation

Description:
The product performs a power save/restore
            operation, but it does not ensure that the integrity of
            the configuration state is maintained and/or verified between
	    the beginning and ending of the operation.

Extended Description:
Before powering down, the Intellectual
                Property (IP) saves current state (S) to persistent
                storage such as flash or always-on memory in order to
                optimize the restore operation.  During this process,
                an attacker with access to the persistent storage may
                alter (S) to a configuration that could potentially
                modify privileges, disable protections, and/or cause
                damage to the hardware. If the IP does not validate
                the configuration state stored in persistent memory,
                upon regaining power or becoming operational again,
                the IP could be compromised through the activation of
                an unwanted/harmful configuration.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: DoS: Instability

Mitigations:
  - [Architecture and Design] Inside the IP, incorporate integrity checking
                        on the configuration state via a cryptographic
                        hash. The hash can be protected inside the IP such as
                        by storing it in internal registers which never lose
                        powe
  - [Integration] Outside the IP, incorporate integrity checking
                        of the configuration state via a trusted agent. Before
                        powering down, the trusted agent performs a hash of the
                        configuration and saves the hash in persistent storage.
              
  - [Integration] Outside the IP, incorporate a protected
                        environment that prevents undetected modification of
                        the configuration state by untrusted agents. Before
                        powering down, a trusted agent saves the IP's
                        configuration

Demonstrative examples:
The following pseudo code demonstrates the
                        power save/restore workflow which may lead to weakness
                        through a lack of validation of the config state after
                        restore.
The following pseudo-code is the proper workflow for the integrity checking mitigation:
void save_config_state() 
						{ 
						 
							void* cfg; 
							 
							cfg = get_config_state(); 
							save_config_state(cfg); 
							 
							go_to_sleep(); 
						 
						} 
						 
						void restore_config_state() 
						{ 
						 
							void* cfg; 
							cfg = get_config_file(); 
							load_config_file(cfg); 
						 
						}
void save_config_state() 
						{ 
						 
							void* cfg; 
							void* sha; 
							 
							cfg = get_config_state(); 
							sa
CWE-1310: Missing Ability to Patch ROM Code

Description:
Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.

Extended Description:
A System or System-on-Chip (SoC) that implements a boot process utilizing security mechanisms such as Root-of-Trust (RoT) typically starts by executing code from a Read-only-Memory (ROM) component. The code in ROM is immutable, hence any security vulnerabilities discovered in the ROM code can never be fixed for the systems that are already in use. 
				
				 A common weakness is that the ROM does not have the ability to patch if security vulnerabilities are uncovered after the system gets shipped.  This leaves the system in a vulnerable state where an adversary can compromise the SoC.

Affected languages: Not Language-Specific
Affected technologies: System on Chip
Parent weaknesses: CWE-1329

Consequences:
  - Other: Varies by Context

Mitigations:
  - [Architecture and Design] Secure patch support to allow ROM code to be patched on the next boot.
  - [Architecture and Design] Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used for limited patching of devices after shipping, or for the next batch of silicon devices manufactured, without changing the full device ROM.

Demonstrative examples:
A System-on-Chip (SOC) implements a Root-of-Trust (RoT) in ROM to boot secure code. However, at times this ROM code might have security vulnerabilities and need to be patched. Since ROM is immutable, it can be impossible to patch.
ROM does not have built-in application-programming interfaces (APIs) to patch if the code is vulnerable. Implement mechanisms to patch the vulnerable ROM code.

The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow users to boot from a ROM for Linux (i_bootrom_linux) or from a patchable ROM (i_bootrom_patch) if the Linux bootrom has security or functional issues.The example code is taken from the SoC peripheral wrapper inside the buggy OpenPiton SoC of HACK@DAC'21. The wrapper is used for connecting the communications between SoC peripherals, such as crypto-engines, direct memory access (DMA), reset controllers, JTAG, etc. The secure implementation of the SoC wrapper should allow us
CWE-1311: Improper Translation of Security Attributes by Fabric Bridge

Description:
The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.

Extended Description:
A bridge allows IP blocks supporting different fabric protocols to be integrated into the system.  Fabric end-points or interfaces usually have dedicated signals to transport security attributes. For example, HPROT signals in AHB, AxPROT signals in AXI, and MReqInfo and SRespInfo signals in OCP. 
				 The values on these signals are used to indicate the security attributes of the transaction. These include the immutable hardware identity of the controller initiating the transaction, privilege level, and type of transaction (e.g., read/write, cacheable/non-cacheable, posted/non-posted). 
				 A weakness can arise if the bridge IP block, which translates the signals from the protocol used in the IP block endpoint to the protocol used by the central bus, does not properly translate the security attributes. As a result, the identity of the initiator could be translated from untrusted to trusted or vice-versa. This could result in access-control bypass, privilege escalation, or denial of se

Affected languages: Verilog, VHDL
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.
  - [Implementation] Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.

Demonstrative examples:
The bridge interfaces between OCP and AHB end points. OCP uses MReqInfo signal to indicate security attributes, whereas AHB uses HPROT signal to indicate the security attributes. The width of MReqInfo can be customized as needed. In this example, MReqInfo is 5-bits wide and carries the privilege level of the OCP controller. 
	        The values 5'h11, 5'h10, 5'h0F, 5'h0D, 5'h0C, 5'h0B, 5'h09, 5'h08, 5'h04, and 5'h02 in MReqInfo indicate that the request is coming from a privileged state of the OCP bus controller. Values 5'h1F, 5'h0E, and 5'h00 indicate untrusted, privilege state. 
	        Though HPROT is a 5-bit signal, we only consider the lower, two bits in this example. HPROT values 2'b00 and 2'b10 are considered trusted, and 2'b01 and 2'b11 are considered untrusted. 
	        The OCP2
CWE-1312: Missing Protection for Mirrored Regions in On-Chip Fabric Firewall

Description:
The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.

Extended Description:
Few fabrics mirror memory and address ranges, where mirrored regions contain copies of the original data. This redundancy is used to achieve fault tolerance. Whatever protections the fabric firewall implements for the original region should also apply to the mirrored regions. If not, an attacker could bypass existing read/write protections by reading from/writing to the mirrored regions to leak or corrupt the original data.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Modify Memory

Detection methods:
  - Manual Dynamic Analysis: Using an external debugger, send write transactions to mirrored regions to test if original, write-protected regions are modified. Similarly, send read transactions to mirrored regions to test if the 

Mitigations:
  - [Architecture and Design] The fabric firewall should apply the same protections as the original region to the mirrored regions.
  - [Implementation] The fabric firewall should apply the same protections as the original region to the mirrored regions.

Demonstrative examples:
A memory-controller IP block is connected to the on-chip fabric in a System on Chip (SoC).  The memory controller is configured to divide the memory into four parts: one original and three mirrored regions inside the memory. The upper two bits of the address indicate which region is being addressed. 00 indicates the original region and 01, 10, and 11 are used to address the mirrored regions. All four regions operate in a lock-step manner and are always synchronized. The firewall in the on-chip fabric is programmed to protect the assets in the memory.
The firewall only protects the original range but not the mirrored regions.
CWE-1313: Hardware Allows Activation of Test or Debug Logic at Runtime

Description:
During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.

Extended Description:
An adversary can take advantage of test or debug logic that is made accessible through the hardware during normal operation to modify the intended behavior of the system. For example, an accessible Test/debug mode may allow read/write access to any system data. Using error injection (a common test/debug feature) during a transmit/receive operation on a bus, data may be modified to produce an unintended message. Similarly, confidentiality could be compromised by such features allowing access to secrets.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of oppor
  - [Implementation] Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of oppor
  - [Integration] Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of oppor

Real-world examples:
  - CVE-2021-33150: Hardware processor allows activation of test or debug logic at runtime.
  - CVE-2021-0146: Processor allows the activation of test or debug logic at runtime, allowing escalation of privileges
CWE-1314: Missing Write Protection for Parametric Data Values

Description:
The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.

Extended Description:
Various sensors are used by hardware to detect any devices operating outside of the design limits. The threshold limit values are set by hardware fuses or trusted software such as the BIOS. These limits may be related to thermal, power, voltage, current, and frequency. Hardware mechanisms may be used to protect against alteration of the threshold limit values by untrusted software. 
				 The limit values are generally programmed in standard units for the type of value being read. However, the hardware-sensor blocks may report the settings in different units depending upon sensor design and operation. The raw sensor output value is converted to the desired units using a scale conversion based on the parametric data programmed into the sensor. The final converted value is then compared with the previously programmed limits. 
				 While the limit values are usually protected, the sensor parametric data values may not be. By changing the parametric data, safe operational limits may be bypa

Affected languages: Not Language-Specific
Affected technologies: Sensor Hardware
Parent weaknesses: CWE-862

Consequences:
  - Availability: Quality Degradation

Mitigations:
  - [Architecture and Design] Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data.

Demonstrative examples:
Malicious software executes instructions to increase power consumption to the highest possible level while causing the clock frequency to increase to its maximum value.
							Such a program executing for an extended period of time would likely overheat the device, possibly resulting in permanent damage to the device.
						 
						 A ring, oscillator-based temperature sensor will generally report the sensed value as
							oscillator frequency rather than degrees centigrade.  The temperature sensor will have
							calibration values that are used to convert the detected frequency into the corresponding temperature in degrees centigrade.
						 
						 Consider a SoC design where the critical maximum temperature limit is set in fuse values to 100C and
							is not modifiable by software.

Real-world examples:
  - CVE-2017-8252: Kernel can inject faults in computations during the execution of TrustZone leading to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electr
CWE-1315: Improper Setting of Bus Controlling Capability in Fabric End-point

Description:
The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.

Extended Description:
To support reusability, certain fabric interfaces and end points provide a configurable register bit that allows IP blocks connected to the controller to access other peripherals connected to the fabric. This allows the end point to be used with devices that function as a controller or responder. If this bit is set by default in hardware, or if firmware incorrectly sets it later, a device intended to be a responder on a fabric is now capable of controlling transactions to other devices and might compromise system security.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Access Control: Modify Memory

Mitigations:
  - [Architecture and Design] For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-contro
  - [Implementation] For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-contro
  - [System Configuration] For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-contro

Demonstrative examples:
A typical, phone platform consists of the main, compute core or CPU, a DRAM-memory chip, an audio codec, a baseband modem, a power-management-integrated circuit ("PMIC"), a connectivity (WiFi and Bluetooth) modem, and several other analog/RF components. The main CPU is the only component that can control transactions, and all the other components are responder-only devices. All the components implement a PCIe end-point to interface with the rest of the platform. The responder devices should have the bus-control-enable bit in the PCIe-end-point register set to 0 in hardware to prevent the devices from controlling transactions to the CPU or other peripherals.
The audio-codec chip does not have the bus-controller-enable-register bit hardcoded to 0.  There is no platform-firmware flow to verif
CWE-1319: Improper Protection against Electromagnetic Fault Injection (EM-FI)

Description:
The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.

Extended Description:
Electromagnetic fault injection may allow an attacker to locally and dynamically modify the signals (both internal and external) of an integrated circuit. EM-FI attacks consist of producing a local, transient magnetic field near the device, inducing current in the device wires. A typical EMFI setup is made up of a pulse injection circuit that generates a high current transient in an EMI coil, producing an abrupt magnetic pulse which couples to the target producing faults in the device, which can lead to: 
				 
				 Bypassing security mechanisms such as secure JTAG or Secure Boot 
				 Leaking device information 
				 Modifying program flow 
				 Perturbing secure hardware modules (e.g. random number generators)

Affected languages: Not Language-Specific
Affected technologies: System on Chip, Microcontroller Hardware, Memory Hardware, Power Management Hardware, Processor Hardware, Test/Debug Hardware, Sensor Hardware
Parent weaknesses: CWE-693

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] 1. Redundancy - By replicating critical operations and comparing the two outputs can help indicate whether a fault has been injected. 
						 2. Error detection and correction codes - Gay, Mael, et al. proposed a new scheme that not only detects faults injected by a malicious adversary but also auto

Demonstrative examples:
In many devices, security related information is stored in fuses. These fuses are loaded into shadow registers at boot time. Disturbing this transfer phase with EM-FI can lead to the shadow registers storing erroneous values potentially resulting in reduced security.
Colin O'Flynn has demonstrated an attack scenario [REF-1144] that uses electro-magnetic glitching during booting to bypass security and gain read access to flash, read and erase access to shadow memory area (where the private password is stored). Most devices in the MPC55xx and MPC56xx series that include the Boot Assist Module (BAM) (a serial or CAN bootloader mode) are susceptible to this attack. In this paper, a GM ECU was used as a real life target. While the success rate appears low (less than 2 percent), in practice a su

Real-world examples:
  - CVE-2020-27211: Chain: microcontroller system-on-chip uses a register value stored in flash to set product protection state on the memory bus and does not contain protection against fault injection (CWE-1319) which l