Currently there is no way to disable GDS mitigation at build time.
Disabling the current config option (GDS_MITIGATION_FORCE) does not
disable the mitigation, but set it to GDS_MITIGATION_FULL, which does
not disable it.
Create a new kernel config that allows GDS to be completely disabled,
similarly to the "gather_data_sampling=off" or "mitigations=off" kernel
command-line. Move the GDS_MITIGATION_FORCE under this new mitigation.
Now, there are three options for GDS mitigation:
* CONFIG_MITIGATION_GDS=n -> Mitigation disabled (New)
* CONFIG_MITIGATION_GDS=y -> Mitigation enabled (GDS_MITIGATION_FULL)
* CONFIG_GDS_MITIGATION_FORCE=y -> Forceful mitigation (disable AVX)
Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/x86/Kconfig | 16 +++++++++++-----
arch/x86/kernel/cpu/bugs.c | 7 ++++---
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a902680b6537..d99b758c8d35 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2607,15 +2607,21 @@ config MITIGATION_SLS
against straight line speculation. The kernel image might be slightly
larger.
+config MITIGATION_GDS
+ bool "Mitigate Gather Data Sampling"
+ depends on CPU_SUP_INTEL
+ default y
+ help
+ Enable mitigation for Gather Data Sampling (GDS). GDS is a hardware
+ vulnerability which allows unprivileged speculative access to data
+ which was previously stored in vector registers. The attacker uses gather
+ instructions to infer the stale vector register data.
+
config MITIGATION_GDS_FORCE
bool "Force GDS Mitigation"
- depends on CPU_SUP_INTEL
+ depends on MITIGATION_GDS
default n
help
- Gather Data Sampling (GDS) is a hardware vulnerability which allows
- unprivileged speculative access to data which was previously stored in
- vector registers.
-
This option is equivalent to setting gather_data_sampling=force on the
command line. The microcode mitigation is used if present, otherwise
AVX is disabled as a mitigation. On affected systems that are missing
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 9a9685c9244b..f2bdfb359f6b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -731,10 +731,11 @@ enum gds_mitigations {
GDS_MITIGATION_HYPERVISOR,
};
-#if IS_ENABLED(CONFIG_MITIGATION_GDS_FORCE)
-static enum gds_mitigations gds_mitigation __ro_after_init = GDS_MITIGATION_FORCE;
+#if IS_ENABLED(CONFIG_MITIGATION_GDS)
+static enum gds_mitigations gds_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_GDS_FORCE) ? GDS_MITIGATION_FORCE : GDS_MITIGATION_FULL;
#else
-static enum gds_mitigations gds_mitigation __ro_after_init = GDS_MITIGATION_FULL;
+static enum gds_mitigations gds_mitigation __ro_after_init = GDS_MITIGATION_OFF;
#endif
static const char * const gds_strings[] = {
--
2.43.0On Mon, Apr 22, 2024 at 09:58:15AM -0700, Breno Leitao wrote:
> +config MITIGATION_GDS
> + bool "Mitigate Gather Data Sampling"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for Gather Data Sampling (GDS). GDS is a hardware
> + vulnerability which allows unprivileged speculative access to data
> + which was previously stored in vector registers. The attacker uses gather
> + instructions to infer the stale vector register data.
> +
> config MITIGATION_GDS_FORCE
Btw, can we get rid of that thing, while at it?
Ubuntu and SLES don't set it, no clue how to check RHEL configs but if it is
not set there, we probably could unify both options...
I'm looking at
53cf5797f114 ("x86/speculation: Add Kconfig option for GDS")
...
Hmmm.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hello Borislav, On Fri, Jul 12, 2024 at 07:21:32PM +0200, Borislav Petkov wrote: > On Mon, Apr 22, 2024 at 09:58:15AM -0700, Breno Leitao wrote: > > +config MITIGATION_GDS > > + bool "Mitigate Gather Data Sampling" > > + depends on CPU_SUP_INTEL > > + default y > > + help > > + Enable mitigation for Gather Data Sampling (GDS). GDS is a hardware > > + vulnerability which allows unprivileged speculative access to data > > + which was previously stored in vector registers. The attacker uses gather > > + instructions to infer the stale vector register data. > > + > > config MITIGATION_GDS_FORCE > > Btw, can we get rid of that thing, while at it? Sure, I will send a v4 and get rid of GDS_FORCE_MITIGATION completely. Thanks for the review. --breno
On Mon, Jul 15, 2024 at 05:14:54AM -0700, Breno Leitao wrote:
> Sure, I will send a v4 and get rid of GDS_FORCE_MITIGATION completely.
I'm actually waiting on the people on Cc to chime in whether we really need
it. The three distro configs we checked, don't set it.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 7/15/24 05:17, Borislav Petkov wrote: > On Mon, Jul 15, 2024 at 05:14:54AM -0700, Breno Leitao wrote: >> Sure, I will send a v4 and get rid of GDS_FORCE_MITIGATION completely. > > I'm actually waiting on the people on Cc to chime in whether we really need > it. The three distro configs we checked, don't set it. > If no one is using it I don't see any reason to keep it. It's just cluttering up the code at that point. End users can still set gather_data_sampling=force anyway.
On Tue, Jul 16, 2024 at 11:51:23AM -0700, Daniel Sneddon wrote:
> If no one is using it I don't see any reason to keep it. It's just
> cluttering up the code at that point. End users can still set
> gather_data_sampling=force anyway.
Yeah, right, thanks for confirming.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Jul 15, 2024 at 02:17:03PM +0200, Borislav Petkov wrote: > On Mon, Jul 15, 2024 at 05:14:54AM -0700, Breno Leitao wrote: > > Sure, I will send a v4 and get rid of GDS_FORCE_MITIGATION completely. > > I'm actually waiting on the people on Cc to chime in whether we really need > it. The three distro configs we checked, don't set it. Makes sense, thanks. Regarding this patchset itself, what is the patch forward? Should I send a rebased version? Thanks --breno
On Mon, Jul 15, 2024 at 06:35:21AM -0700, Breno Leitao wrote:
> Regarding this patchset itself, what is the patch forward?
The path forward is for you to wait until I've gone through them all. We have
merge window now so not in the next two weeks.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Jul 15, 2024 at 03:43:37PM +0200, Borislav Petkov wrote: > On Mon, Jul 15, 2024 at 06:35:21AM -0700, Breno Leitao wrote: > > Regarding this patchset itself, what is the patch forward? > > The path forward is for you to wait until I've gone through them all. We have > merge window now so not in the next two weeks. That is fair, I didn't mean to rush at all. Thanks for looking at these patches! --breno
© 2016 - 2026 Red Hat, Inc.