Threat Analysis Guidance for Gather Data Sampling

Gather Data Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processors. Intel will provide a microcode update with a mitigation for GDS for those affected processors. This mitigation will be enabled by default. This microcode will also provide an opt-out mechanism to disable the mitigation, and operating systems are using these microcode controls to provide a mechanism for end users to enable and disable the mitigation.

The GDS mitigation might have some potential performance impact on certain workloads depending on the instructions used by those workloads. This document provides guidance for system administrators and users to perform a threat analysis and to assess their potential exposure to the exploit and to decide whether to apply the mitigation to their specific environment. Users can combine their threat analysis with a characterization of the performance impact of this mitigation in their workloads to make an informed decision about whether to enable or disable the mitigation on their systems. For additional information, refer to the Gather Data Sampling Mitigation Performance Analysis. 

Always keep your systems up-to-date with the latest security updates and follow the guidance from your software vendors. 

Threat Analysis

A GDS transient execution attack has similar characteristics as Microarchitectural Data Sampling (MDS) in terms of exploitability. Since a GDS transient execution attack uses the data sampling method to extract information, the attacker is required to run on the same core as the victim to extract a certain amount of raw stale data and then perform analysis over this data to infer useful information. Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment. Refer to the Attack Requirements section for further details about the requirements for a successful attack. 

GDS differs from the MDS vulnerabilities in both the method of exposure (which is limited to the set of gather instructions), and in the data exposed (stale vector register data only). Neither MDS nor GDS, by themselves, provide malicious actors the ability to choose which data is inferred using these methods. Systems which are exposed to malicious software capable of executing a GDS attack may be exposed to more practical attacks that are easier to implement than GDS.

This section outlines details of certain attack preconditions that must exist for the possibility of successful exploitation of this vulnerability, discussion of performance considerations, and the available mitigations and options that exist for customers evaluating GDS as part of their threat analysis and management activities. 

Attack Requirements

The key conditions required for a successful GDS attack on an unmitigated system are listed below:

1. The attacker must be able to execute malicious code on the same physical core as the target. This requires that the attacker has access to the same system as the target software, and has sufficient control to both identify which physical core the target software is executing on, and also ensure that they can run their malicious code on that same core.
2. The attacker needs to execute malicious code which uses gather instructions to transiently sample stale data from the vector register file and transmit that data using a disclosure gadget. The information that the attacker can infer is limited to data that was present in architectural or internal vector registers.
3. Once data sampling is completed, the attacker needs to perform data analysis to determine whether the sampled data contains the targeted information, and then infer useful information from the raw sampled data.

Threat Model Considerations

Users without administrative access will likely not be able to disable the GDS mitigation. Privileged users need to take into consideration their threat model and understand both the requirements for a potential successful attack described above and how their systems are used when deciding whether to disable the GDS mitigation.

Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment. 

Deployment Scenarios to Consider

• Systems running only trusted code: If all the code running on the system, including third-party libraries, is considered trusted, then the potential exposure for a GDS attack is low. 
  • The exposure to potential GDS attacks is low for on-site enterprise systems or heavily access-controlled systems with limited user access and limited, trusted applications.
  • Systems with different security policies for different trust groups, where only authorized trusted users can access the systems which handle a given type of sensitive or private data are also at low exposure to GDS attacks.

• Systems running untrusted code: Systems allowed to run untrusted code have higher exposure to potential GDS attacks. 
  • Note that managed runtimes typically do not directly generate gather instructions; for example, V8* does not currently generate gather instructions for JavaScript* code. For just-in time compilation, the exposure is low.

• Single-user systems: If only one user has access to the system, and untrusted code is not allowed to run in the system, the potential for exposure to this threat is low.  This is also the case for systems that are shared by multiple users but for which only one user is allowed to use the system at a time; for example, when a job scheduler is used in a cluster and the minimum allocatable resource is a full compute node. This is a typical setup found in many on-premises high-performance computing (HPC) systems. 
  In those HPC installations, compute nodes are not shared between two different users at any time. Only once a job finishes will a new job be allocated in the same node, with some epilog/prolog process in between jobs. In this scenario, a potential GDS attack is less likely to infer useful data. 
  However, it might be the case in these systems that there are shared nodes, like login or development nodes, where multiple users have concurrent access to the same system. Even though the potential exposure in this type of node may be relatively higher, there are additional security factors to consider for shared nodes that are more exposed to such risks.
  The exception to these statements about single-user systems is when untrusted code is allowed to run in the system. See above for considerations that apply to systems where untrusted code is allowed to run.

• Shared multi-tenant systems: When there are multiple users to share the same core in a cloud environment, especially when the core is oversubscribed, tenants are constantly changing and with that, data usage is consistently changing, therefore the window for an attacker to target particular data for GDS sampling is limited in a real-world deployment scenario. Data sampling attacks like GDS are just one of many possible attacks that may be difficult to carry out successfully outside of a controlled lab environment, given these conditions. Shared multi-tenant systems which exclusively handle low-value assets may be assumed to be less valuable targets for attacks like GDS than systems which handle secret data.

Performance Considerations

The GDS mitigation will impact the performance of the gather instructions provided by Intel Advanced Vector Extensions 2 (Intel® AVX2) and Intel Advanced Vector Extensions 512 (Intel® AVX-512) and, in the cases noted in the technical documentation, the performance of the clwb instruction in some of the affected platforms. Thus, only applications that use those instructions may see a performance impact from this mitigation. Typically, applications that rely on gather instructions are typically heavily vectorized applications that can be normally found in scientific and visualization engineering fields. In these cases, unless the gather instructions are implemented through intrinsics, different compilers might generate different numbers of gather instructions. This might result in the mitigation having diverse performance impacts depending on how the compiler vectorizes the code.

The clwb instruction is normally only found in applications using non-volatile memory. Those could be applications like databases, or other heavy I/O codes, when running on non-volatile memory. The performance impact on this specific clwb instruction is limited to a few Intel processors as described in the GDS technical documentation.

System Administrator Considerations

System administrators concerned about a potential GDS attack should ask themselves the following questions:

1. Are my workloads seeing a performance impact from the GDS mitigation?
2. What does it take to infer relevant data?
3. Is there untrusted code? Are installed third-party libraries reviewed?
   • An attacker can typically only exploit GDS if they are already able to run arbitrary malicious code on a system.
4. Is software up to date?

Opt-in and Opt-out

The GDS mitigation is turned on by default in the microcode. Operating system vendors (OSVs) may implement options to opt out of the GDS mitigation. For users, it is best to use the OS option to turn off mitigation if this is the option chosen.

For confident privileged users, there may be additional options to configure the mitigation, including using msr-tools. 

Refer to the GDS technical documentation for more details. Additional information will be added in future revisions of this document.

The table below provides a summary of where different types of users may consider enabling or disabling the GDS mitigation. This table does not provide all-inclusive guidance and does not consider all attack vectors. Users should decide the mitigation control according to their threat model. 

Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources