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 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).
RDSEED instruction retrieves a hardware-generated random seed value from the on-CPU entropy source. Like
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
RDSEED. Refer to the SRBDS deep dive for more details.
On affected processors, Intel will release microcode updates whose default behavior intends to prevent
RDSEED results from being inferred through SRBDS. The updated microcode delays off-core accesses from other logical processors while the
RDSEED instructions execute.
This can have three effects on performance:
RDSEEDinstructions will have higher latency.
RDRANDat the same time on multiple logical processors will be serialized, resulting in an overall reduction in the maximum
RDSEEDwill 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™3, 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
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
IA32_MCU_OPT_CTRL MSR (address
IA32_MCU_OPT_CTRL (RNGDS_MITG_DIS) to 1 for a logical processor disables the mitigation for
RDSEED executed outside of an Intel SGX enclave on that logical processor
If usage of
RDSEED is very frequent, system administrators may choose to opt out of the mitigation if any of the following are true:
RDSEEDare 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).
RDSEEDoutput is securely mixed with other sources of entropy before use (for example, in the Linux*
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.