2299
system software. For example, Linux supports these checks for many commodity processors:
$ cat /proc/cpuinfo | grep bugs | head -n 1 bugs : cpu_meltdown spectre_v1 spectre_v2
spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed
Effectiveness = High
This method can be useful for detecting whether a processor if affected by known weaknesses,
but it may not be useful for detecting unknown weaknesses.
Potential Mitigations
Phase: Architecture and Design
The hardware designer can attempt to prevent transient execution from causing observable
discrepancies in specific covert channels.
Effectiveness = Limited
Instructions or features that constrain transient execution or suppress its side effects may impact
performance.
Phase: Requirements
Processor designers, system software vendors, or other agents may choose to restrict the ability
of unprivileged software to access to high-resolution timers that are commonly used to monitor
covert channels.
Effectiveness = Defense in Depth
Disabling specific predictors or other hardware features may result in significant performance
overhead.
Phase: Requirements
Processor designers may expose instructions or other architectural features that allow software
to mitigate the effects of transient execution, but without disabling predictors. These features may
also help to limit opportunities for data exposure.
Effectiveness = Moderate
Instructions or features that constrain transient execution or suppress its side effects may impact
performance.
Phase: Requirements
Processor designers may expose registers (for example, control registers or model-specific
registers) that allow privileged and/or user software to disable specific predictors or other
hardware features that can cause confidential data to be exposed during transient execution.
Effectiveness = Limited
Disabling specific predictors or other hardware features may result in significant performance
overhead.
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: Build and Compilation
Isolate sandboxes or managed runtimes in separate address spaces (separate processes).
CWE Version 4.14
CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient
Execution
CWE-1422: Exposure of Sensitive Information caused by
Incorrect Data Forwarding during Transient Execution 2300
Effectiveness = High
Process isolation is also an effective strategy to mitigate many other kinds of weaknesses.
Phase: Build and Compilation
Include serialization instructions (for example, LFENCE) that prevent processor events or
mis-predictions prior to the serialization instruction from causing transient execution after the
serialization instruction. For some weaknesses, a serialization instruction can also prevent a
processor event or a mis-prediction from occurring after the serialization instruction (for example,
CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store;
a serialization instruction between the store and the load may allow the store to update memory
and prevent the mis-prediction from happening at all).
Effectiveness = Moderate
When used to comprehensively mitigate a transient execution weakness, serialization
instructions can introduce significant performance overhead.
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 this technique to mitigate bounds-check bypass [REF-1390].
Phase: Build and Compilation
If the weakness is exposed by a single instruction (or a small set of instructions), then the
compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being
generated, and instead generate an alternate sequence of instructions that is not affected by the
weakness.
Effectiveness = Limited
This technique is only effective for software that is compiled with this mitigation.
Phase: Documentation
If a hardware feature can allow incorrect or stale data to be forwarded to transient operations,
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:
Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secretdependent
traces in the microarchitectural state. Consider this code sequence example from
[REF-1391].
Example Language: C (Bad)
void call_victim(size_t untrusted_arg) {
*arg_copy = untrusted_arg;
array[**trusted_ptr * 4096];
}
CWE Version 4.14
CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient
Execution
CWE-1422: Exposure of Sensitive Information caused by
Incorrect Data Forwarding during Transient Execution