Intel® Secure Key is a digital random number generator located on the CPU that provides software applications with high quality pseudorandom numbers and random seeds. Software applications access this capability through the RDRAND and RDSEED instructions.
The RDRAND instruction retrieves a random value that is either 16-, 32-, or 64-bits, as determined by the size of the destination register. RDRAND is intended for use by applications that require high-quality random numbers, but is not directly suitable for seeding other pseudorandom number generators (PRNGs).
The RDSEED instruction retrieves a hardware-generated random seed value from the on-CPU entropy source. Like RDRAND, the RDSEED instruction retrieves a 16-, 32-, or 64-bit value, and has no hardware ring requirements. Unlike RDRAND, the values of RDSEED can be concatenated together to form arbitrarily long random seed values that retain their full entropy. The primary use case for RDSEED is to produce seeds of arbitrary size for software PRNGs.
On some client and Intel® Xeon® E3 and E processors, a domain bypass transient execution attack known as special register buffer data sampling (SRBDS) may potentially allow malicious code executing on any core of the CPU to infer the data values returned by RDRAND and RDSEED. Refer to Special Register Buffer Data Sampling for more details.
Impact of SRBDS Mitigation on RDRAND and RDSEED
On affected processors, Intel will release microcode updates whose default behavior intends to prevent RDRAND and RDSEED results from being inferred through SRBDS. The updated microcode delays off-core accesses from other logical processors while the RDRAND or RDSEED instructions execute.
This can have three effects on performance:
- The RDRAND or RDSEED instructions will have higher latency.
- Executions of RDRAND at the same time on multiple logical processors will be serialized, resulting in an overall reduction in the maximum RDRAND bandwidth1.
- Executing RDRAND or RDSEED will delay memory accesses from other logical processors that miss their core caches, with an impact similar to legacy locked cache-line-split accesses.
This mitigation has a very minimal impact on client workloads, as it is not typical for clients to issue bulk requests for random numbers at high rates. Random number generation is generally a very small fraction of a larger operation, and the added latencies are not significant compared to the overall workload. The mitigation should also have a minimal impact on most single-socket server workloads for the same reasons. Only specialized applications which call RDRAND for a high throughput of random numbers will see a noticeable performance impact.
System administrators can determine if workloads might be affected by the RDRAND performance impact by monitoring CPU utilization of processes that do frequent TLS connections. Tools that can help with performance monitoring include Toplev2 and Intel® VTune™ Profiler3, among others. System administrators can find more information in the system administrator's guide.
A workload that is potentially impacted by SRBDS can use performance monitoring events to determine if the impact is caused by the mitigation. Using the TopDown methodology, workloads affected by the SRBDS mitigation may observe an increase in Frontend Bound. Specifically, SRBDS may show an impact in the Frontend Bound > Frontend Latency > Branch Resteers > Clears Resteers component of Top Down, increasing the count of the INT_MISC.CLEAR_RESTEER_CYCLES event. Other events that may show increased count if an application’s performance is impacted by the SRBDS mitigation include MACHINE_CLEARS.COUNT and PARTIAL_RAT_STALLS.SCOREBOARD.
Methods to Reduce Mitigation Performance Impact
There are two methods to reduce the performance impact of the SRBDS mitigations.
The first technique is to turn off the SRBDS mitigation. This can be done through setting the RNGDS_MITG_DIS4 bit (bit 0) of IA32_MCU_OPT_CTRL MSR (address 123H). Setting IA32_MCU_OPT_CTRL (RNGDS_MITG_DIS) to 1 for a logical processor disables the mitigation for RDRAND and RDSEED executed outside of an Intel® Software Guard Extensions (Intel® SGX) enclave on that logical processor.
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).
The second technique is to use software configurations that reduce the frequency of RDRAND usage. For example, you can disable the RDRAND engine in OpenSSL. More generally, RDSEED can be used to seed a software-based pseudo-random number generator (PRNG) instead of directly using RDRAND for those random numbers. If RDSEED is not available on the target platform, then the application can use the “seed from RDRAND” method for occasional reseeding.
- Intel® Digital Random Number Generator (DRNG) Software Implementation Guide
- The Difference Between RDRAND and RDSEED
- A Top-Down method for performance analysis and counters architecture
- Although this is also true for RDSEED, the parallelism of RDSEED is already limited by the availability of entropy.
- GitHub* andikleen/pmu-tools
- Intel® VTune™ Profiler
- More details on RNGDS_MITG_DIS and IA32_MCU_OPT_CTRL are available in Special Register Buffer Data Sampling.
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources