2288
This technique may only be effective for software that is compiled with this mitigation. For some
transient execution weaknesses, this technique may not be sufficient to protect software that is
compiled without the affected instruction(s). For example, see CWE-1421.
Phase: Build and Compilation
Use software techniques that can mitigate the consequences of transient execution. For
example, address masking can be used in some circumstances to prevent out-of-bounds
transient reads.
Effectiveness = Limited
Address masking and related software mitigation techniques have been used to harden specific
code sequences that could potentially be exploited via transient execution. For example, the
Linux kernel makes limited use of manually inserted address masks to mitigate bounds-check
bypass [REF-1390]. Compiler-based techniques have also been used to automatically harden
software [REF-1425].
Phase: Build and Compilation
Use software techniques (including the use of serialization instructions) that are intended to
reduce the number of instructions that can be executed transiently after a processor event or
misprediction.
Effectiveness = Incidental
Some transient execution weaknesses can be exploited even if a single instruction is executed
transiently after a processor event or mis-prediction. This mitigation strategy has many other
pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].
Phase: Documentation
If a hardware feature can allow incorrect operations (or correct operations with incorrect data)
to execute transiently, the hardware designer may opt to disclose this behavior in architecture
documentation. This documentation can inform users about potential consequences and
effective mitigations.
Effectiveness = High
Demonstrative Examples
Example 1:
Secure programs perform bounds checking before accessing an array if the source of the array
index is provided by an untrusted source such as user input. In the code below, data from array1
will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:
Example Language: C (Bad)
if (x < array1_size)
y = array2[array1[x] * 4096];
However, if this code executes on a processor that performs conditional branch prediction the
outcome of the if statement could be mis-predicted and the access on the next line will occur with a
value of x that can point to an out-of-bounds location (within the program's memory).
Even though the processor does not commit the architectural effects of the mis-predicted branch,
the memory accesses alter data cache state, which is not rolled back after the branch is resolved.
The cache state can reveal array1[x] thereby providing a mechanism to recover the data value
located at address array1 + x.
Example 2:
Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code
with new code. When the instruction pointer enters the new code, the processor may inadvertently
CWE Version 4.14
CWE-1420: Exposure of Sensitive Information during Transient Execution
CWE-1420: Exposure of Sensitive Information during Transient Execution