2284
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Operating_System : Not OS-Specific (Prevalence = Undetermined)
Architecture : Not Architecture-Specific (Prevalence = Undetermined)
Technology : Microcontroller Hardware (Prevalence = Undetermined)
Technology : Processor Hardware (Prevalence = Undetermined)
Technology : Memory Hardware (Prevalence = Undetermined)
Technology : System on Chip (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality Read Memory Medium
Detection Methods
Manual Analysis
This weakness can be detected in hardware by manually inspecting processor specifications.
Features that exhibit this weakness may have microarchitectural predictor state that is shared
between hardware threads, execution contexts (for example, user and kernel), or other
components that may host mutually distrusting software (or firmware, etc.).
Effectiveness = Moderate
Manual analysis may not reveal all weaknesses in a processor specification and should be
combined with other detection methods to improve coverage.
Automated Analysis
CWE Version 4.14
CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State
that Influences Transient Execution
CWE-1423: Exposure of Sensitive Information caused by Shared
Microarchitectural Predictor State that Influences Transient Execution 2304
Software vendors can release tools that detect presence of known weaknesses on a processor.
For example, some of these tools can attempt to transiently execute a vulnerable code sequence
and detect whether code successfully leaks data in a manner consistent with the weakness
under test. Alternatively, some hardware vendors provide enumeration for the presence of a
weakness (or lack of a weakness). These enumeration bits can be checked and reported by
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
Automated Analysis
This weakness can be detected in hardware by employing static or dynamic taint analysis
methods [REF-1401]. These methods can label each predictor entry (or prediction history, etc.)
according to the processor context that created it. Taint analysis or information flow analysis can
then be applied to detect when predictor state created in one context can influence predictions
made in another context.
Effectiveness = Moderate
Automated static or dynamic taint analysis may not reveal all weaknesses in a processor
specification and should be combined with other detection methods to improve coverage.
Potential Mitigations
Phase: Architecture and Design
The hardware designer can attempt to prevent transient execution from causing observable
discrepancies in specific covert channels.
Phase: Architecture and Design
Hardware designers may choose to use microarchitectural bits to tag predictor entries. For
example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates
that the predictor entry was created in kernel mode. The processor can use this bit to enforce
that predictions in the current mode must have been trained in the current mode. This can
prevent malicious cross-mode training, such as when user-mode software attempts to create
predictor entries that influence transient execution in the kernel. Predictor entry tags can also
be used to associate each predictor entry with the SMT thread that created it, and thus the
processor can enforce that each predictor entry can only be used by the SMT thread that created
it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling
SMT thread.
Effectiveness = Moderate
Tagging can be highly effective for predictor state that is comprised of discrete elements, such as
an array of recently visited branch targets. Predictor state can also have different representations
that are not conducive to tagging. For example, some processors keep a compressed digest of
branch history which does not contain discrete elements that can be individually tagged.
Phase: Architecture and Design
Hardware designers may choose to sanitize microarchitectural predictor state (for example,
branch prediction history) when the processor transitions to a different context, for example,
whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that
allow software to sanitize predictor state according to the user's threat model. For example, this
can allow operating system software to sanitize predictor state when performing a context switch
from one process to another.
Effectiveness = Moderate
CWE Version 4.14
CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State
that Influences Transient Execution
CWE-1423: Exposure of Sensitive Information caused by Shared
Microarchitectural Predictor State that Influences Transient Execution