This technical documentation expands on the information the special register buffer data sampling disclosure for software developers. Be sure to review the updated terminology guide and the list of Affected Processors (2018-2021 tab, Special Register Buffer Data Sampling column).
A new domain bypass transient execution attack known as special register buffer data sampling (SRBDS) may allow data values from special registers to be inferred by malicious code executing on any core of the CPU. This vulnerability affects some client and Intel® Xeon® E3 processors; it does not affect other Intel Xeon or Intel Atom® processors. SRBDS has been assigned CVE-2020-0543 with a base score of CVSS 6.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N.
Certain processor operations (such as RDRAND) microarchitecturally need to read data from outside the physical core (for example, from a random number generator shared between cores). This is often performed through an internal microarchitectural operation called a special register read.
On some processors, the data returned for a special register read is staged in a shared microarchitectural buffer and then transferred to the microarchitectural fill buffer within the physical core that performed the read. That core can then use the value from the microarchitectural fill buffer (for example, the core could copy the value into software-visible registers). This shared buffer is often larger than the data being read (the buffer is usually the size of a cache line), and different special register reads may use different offsets within the shared buffer.
Overview
On affected processors, when the shared staging buffer is updated on a read, only the portion of the staging buffer needed for that read is updated. The other portions of the staging buffer are not modified. The unmodified portions of the staging buffer may contain stale data from previous special register reads, including those done by other cores.
Because the entire shared staging buffer for the special register reads is copied into the fill buffer of the core doing the read, this means that the fill buffer doing the read may contain stale data from previous special register reads. On processors affected by Microarchitectural Fill Buffer Data Sampling (MFBDS) or Intel® Transactional Synchronization Extensions (Intel® TSX) Asynchronous Abort (TAA), an adversary may be able to infer data in the fill buffer entries.
This means that on affected processors that are also affected by MFBDS or TAA, it may be possible for software to infer the value returned by special register reads on other logical processors (including other physical cores) by using MFBDS or TAA techniques. Only the value that was present in the staging buffer used by special register reads can be inferred cross-core.
According to Intel’s evaluation, the special register reads that may be used in methods that rely on their data being kept secret are:
- RDRAND1
- RDSEED
- SGX EGETKEY
Intel has developed mitigations for these special register reads.
Impacts and Use Cases
RDRAND and RDSEED may be used in methods that rely on the data returned being kept secret from potentially malicious actors on other physical cores. For example, random numbers from RDRAND or RDSEED may be used as the basis for a session encryption key. If these values are leaked, an adversary potentially may be able to derive the encryption key.
Mitigations
On affected processors, Intel has released microcode updates whose default behavior is to modify the RDRAND, RDSEED, and EGETKEY instructions to overwrite stale special register data in the shared staging buffer before the stale data can be accessed by any other logical processor on the same core or on a different core.
During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core accesses from other logical processors will be delayed until the special register read is complete and the stale data in the shared staging buffer is overwritten.
This has three effects on performance:
- The RDRAND, RDSEED, or EGETKEY instructions will have higher latency.
- Executing RDRAND at the same time on multiple logical processors will be serialized, resulting in an overall reduction in the maximum RDRAND bandwidth2.
- Executing RDRAND, RDSEED, or EGETKEY will delay memory accesses from other logical processors that miss their core caches, with an impact similar to legacy locked cache-line-split accesses.
Many client systems do not run software that uses RDRAND, RDSEED, or EGETKEY often enough to have significant performance impact. However, some types of software may be impacted; especially some workloads more commonly run on servers.
On systems that have loaded the microcode with the mitigation, the processors are fully mitigated by default.
The microcode updates also provide an opt-out mechanism (RNGDS_MITG_DIS) to disable the mitigation for RDRAND and RDSEED instructions executed outside of Intel® Software Guard Extensions (Intel® SGX) enclaves. On logical processors that disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not take longer to execute and do not impact the performance of sibling logical processors’ memory accesses. The opt-out mechanism does not affect Intel SGX enclaves (including execution of RDRAND or RDSEED inside of an enclave, as well as EGETKEY execution).
If usage of RDRAND/RDSEED is very frequent, system administrators may choose to opt out of the mitigation if any of the following are true:
- There is no untrusted software running on the system.
- OSes that disable the mitigation because they only run trusted applications may also wish to check if they are virtualized in order to ensure no untrusted guests can observe their RDRAND or RDSEED values.
- RDRAND or RDSEED are only used for applications where the secrecy of the random value is not important for security (for example, for a nonce, or to seed pseudo-random number generators for Monte Carlo simulations).
- RDRAND or RDSEED output is securely mixed with other sources of entropy before use (for example, in the Linux* getrandom(2) system call).
On processors that enumerate MDS_NO and RNGDS_MITG_DIS support3 and have Intel TSX disabled (including through IA32_TSX_CTRL being used to disable Intel TSX), the OS should set RNGDS_MITG_DIS. This is because disabling Intel TSX on these processors will block this attack, so the mitigation for RDRAND and RDSEED is not needed.
IA32_MCU_OPT_CTRL MSR Definition
Along with the mitigation for this issue, Intel added a new thread-scope IA32_MCU_OPT_CTRL MSR (address 123H). The presence of this MSR and RNGDS_MITG_DIS (bit 0) is enumerated by CPUID (EAX=07H,ECX=0).EDX[SRBDS_CTRL = 9]==1. This MSR may be introduced through a microcode update.
Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX enclave on that logical processor. Opting out of the mitigation for a particular logical processor does not affect the RDRAND and RDSEED mitigations for other logical processors.
Note that inside of an Intel SGX enclave, the mitigation is applied regardless of the value of RNGDS_MITG_DS.
| Register Address Hex | Register Address Dec | MSR Name / Bit Fields | MSR / Bit Description | Comment |
|---|---|---|---|---|
| 123H | 291 | IA32_MCU_OPT_CTRL | Microcode Update Option Control (R/W) | If CPUID.(EAX=07H, ECX=0):EDX[9]=1 |
| 0 |
RNGDS_MITG_DIS (R/W) |
If CPUID.(EAX=07H, ECX=0):EDX[9]=1 |
||
| 63:1 | Reserved |
Related Content
Footnotes
- EGETKEY is executed through the EGETKEY leaf of the ENCLU instruction but will be referred to in this document simply as EGETKEY instead of ENCLU[EGETKEY].
- Although this is also true for RDSEED or EGETKEY, the parallelism of these instructions are already limited by the availability of entropy.
- RNGDS_MITG_DIS support is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL = 9]==1
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources