linux-kernel - [PATCH v2 0/3] x86/bugs: Separate config for mitigations (part 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240208174555.44200-1-leitao@debian.org>
Date: Thu,  8 Feb 2024 09:45:52 -0800
From: Breno Leitao <leitao@...ian.org>
To: mingo@...hat.com
Cc: jpoimboe@...nel.org,
	x86@...nel.org,
	tglx@...utronix.de,
	bp@...en8.de,
	linux-kernel@...r.kernel.org,
	pawan.kumar.gupta@...ux.intel.com
Subject: [PATCH v2 0/3] x86/bugs: Separate config for mitigations (part 2)

The current CONFIG_SPECULATION_MITIGATIONS namespace is only
halfway populated, where some mitigations have entries in Kconfig, and
they could be modified, while others mitigations do not have Kconfig
entries, and can not be controlled at build time.

Fine-grained control over these Kconfig entries can help in a number of ways:

1) Users can choose and pick only mitigations that are important for
 their workloads.

2) Users and developers can choose to disable mitigations that mangle
 the assembly code generation, making it hard to read.

3) Separate Kconfigs for just source code readability,
 so that we see *which* butt-ugly piece of crap code is for what
 reason...

In most cases, if a mitigation is disabled at compilation time, it
can still be enabled at runtime using kernel command line arguments.

This is the second part of the initial patchset[1] that got half landed.
The first patch did some code re-organization. This second part
contains the exact missing patches from the initial patchset, and
basically adds build-time configuration for the other mitigations that
are currently only disabled at boot time.

Here is a detailed view of each patch:

Patch 1: Create a Kconfig to disable GDS mitigation.
Patch 2: Make spectre v2 userspace mitigation dependent on kernel
         mitigations.
Patch 3: Add a Kconfig entry for each mitigation that doesn't have such

With this patch applied, setting CONFIG_SPECULATION_MITIGATIONS=n, a
simple script[2] shows that all the mitigations are disabled:

  spectre_v2_user_stibp   	 SPECTRE_V2_USER_NONE
  spectre_v2_user_ibpb    	 SPECTRE_V2_USER_NONE
  spectre_v2_cmd          	 SPECTRE_V2_CMD_NONE
  ssb_mode                	 SPEC_STORE_BYPASS_NONE
  l1tf_mitigation         	 L1TF_MITIGATION_OFF
  srso_mitigation         	 SRSO_MITIGATION_NONE
  srso_cmd                	 SRSO_CMD_SAFE_RET
  mds_mitigation          	 MDS_MITIGATION_OFF
  taa_mitigation          	 TAA_MITIGATION_OFF
  mmio_mitigation         	 MMIO_MITIGATION_OFF
  srbds_mitigation        	 SRBDS_MITIGATION_OFF
  gds_mitigation          	 GDS_MITIGATION_OFF
  spectre_v1_mitigation   	 SPECTRE_V1_MITIGATION_NONE
  spectre_v2_enabled      	 SPECTRE_V2_NONE
  retbleed_mitigation     	 RETBLEED_MITIGATION_NONE

[1] https://lore.kernel.org/all/ZZ7c9EbJ71zU5TOF@gmail.com/#t
[2] https://github.com/leitao/debug/blob/main/spec/dump_speculation.py

Changelog:

v1:
  * https://lore.kernel.org/all/20240118173213.2008115-1-leitao@debian.org/

v2:
  * Patch 2: Changed `mode` type from int to `enum spectre_v2_user_cmd`
    as suggested by Pawan Gupta
  * Patch 3: Change MITIGATION_RETBLEED dependency to match the code.

PS: This patchset is against tip/x86/bugs branch.

Breno Leitao (3):
  x86/bugs: Create a way to disable GDS mitigation
  x86/bugs: spectre_v2_user default mode depends on main default
  x86/bugs: Add a separate config for missing mitigation

 arch/x86/Kconfig           | 117 +++++++++++++++++++++++++++++++++++--
 arch/x86/kernel/cpu/bugs.c |  56 +++++++++++-------
 2 files changed, 147 insertions(+), 26 deletions(-)

-- 
2.39.3