Documentation/admin-guide/hw-vuln/gather_data_sampling.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/hw-vuln/gather_data_sampling.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
Extension
.rst
Size
5095 bytes
Lines
110
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

GDS - Gather Data Sampling
==========================

Gather Data Sampling is a hardware vulnerability which allows unprivileged
speculative access to data which was previously stored in vector registers.

Problem
-------
When a gather instruction performs loads from memory, different data elements
are merged into the destination vector register. However, when a gather
instruction that is transiently executed encounters a fault, stale data from
architectural or internal vector registers may get transiently forwarded to the
destination vector register instead. This will allow a malicious attacker to
infer stale data using typical side channel techniques like cache timing
attacks. GDS is a purely sampling-based attack.

The attacker uses gather instructions to infer the stale vector register data.
The victim does not need to do anything special other than use the vector
registers. The victim does not need to use gather instructions to be
vulnerable.

Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks
are possible.

Attack scenarios
----------------
Without mitigation, GDS can infer stale data across virtually all
permission boundaries:

	Non-enclaves can infer SGX enclave data
	Userspace can infer kernel data
	Guests can infer data from hosts
	Guest can infer guest from other guests
	Users can infer data from other users

Because of this, it is important to ensure that the mitigation stays enabled in
lower-privilege contexts like guests and when running outside SGX enclaves.

The hardware enforces the mitigation for SGX. Likewise, VMMs should  ensure
that guests are not allowed to disable the GDS mitigation. If a host erred and
allowed this, a guest could theoretically disable GDS mitigation, mount an
attack, and re-enable it.

Mitigation mechanism
--------------------
This issue is mitigated in microcode. The microcode defines the following new
bits:

 ================================   ===   ============================
 IA32_ARCH_CAPABILITIES[GDS_CTRL]   R/O   Enumerates GDS vulnerability
                                          and mitigation support.
 IA32_ARCH_CAPABILITIES[GDS_NO]     R/O   Processor is not vulnerable.
 IA32_MCU_OPT_CTRL[GDS_MITG_DIS]    R/W   Disables the mitigation
                                          0 by default.
 IA32_MCU_OPT_CTRL[GDS_MITG_LOCK]   R/W   Locks GDS_MITG_DIS=0. Writes
                                          to GDS_MITG_DIS are ignored
                                          Can't be cleared once set.
 ================================   ===   ============================

GDS can also be mitigated on systems that don't have updated microcode by
disabling AVX. This can be done by setting gather_data_sampling="force" or
"clearcpuid=avx" on the kernel command-line.

If used, these options will disable AVX use by turning off XSAVE YMM support.
However, the processor will still enumerate AVX support.  Userspace that
does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
support will break.

Annotation

Implementation Notes