Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
where some mitigations have entries in Kconfig, and they could be
modified, while others mitigations do not have Kconfig entries, and
could not be controlled at build time.
Create an entry for each CPU mitigation under
CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
them at compilation time.
Signed-off-by: Breno Leitao <[email protected]>
---
arch/x86/Kconfig | 93 ++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/bugs.c | 39 ++++++++++------
2 files changed, 117 insertions(+), 15 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a5cada7443ea..ccdcb1dcdc0c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2591,6 +2591,99 @@ config MITIGATION_GDS_FORCE
If in doubt, say N.
+config MITIGATION_MDS
+ bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
+ depends on CPU_SUP_INTEL
+ default y
+ help
+ Enable mitigation for Microarchitectural Data Sampling (MDS). MDS is
+ a hardware vulnerability which allows unprivileged speculative access
+ to data which is available in various CPU internal buffer. Deeper
+ technical information is available in the MDS specific x86 architecture
+ section: Documentation/arch/x86/mds.rst.
+
+config MITIGATION_TAA
+ bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
+ depends on CPU_SUP_INTEL
+ default y
+ help
+ Enable mitigation for TSX Asynchronous Abort (TAA). TAA is a hardware
+ vulnerability that allows unprivileged speculative access to data
+ which is available in various CPU internal buffers by using
+ asynchronous aborts within an Intel TSX transactional region.
+
+config MITIGATION_MMIO_STALE_DATA
+ bool "Mitigate MMIO Stale Data hardware bug"
+ depends on CPU_SUP_INTEL
+ default y
+ help
+ Enable mitigation for MMIO Stale Data hardware bugs. Processor MMIO
+ Stale Data Vulnerabilities are a class of memory-mapped I/O (MMIO)
+ vulnerabilities that can expose data. The vulnerabilities require the
+ attacker to have access to MMIO.
+
+config MITIGATION_L1TF
+ bool "Mitigate L1 Terminal Fault (L1TF) hardware bug"
+ default y
+ help
+ Mitigate L1 Terminal Fault (L1TF) hardware bug. L1 Terminal Fault is a
+ hardware vulnerability which allows unprivileged speculative access to data
+ which is available in the Level 1 Data Cache when the page table
+ entry controlling the virtual address.
+
+config MITIGATION_RETBLEED
+ bool "Mitigate RETBleed hardware bug"
+ default y
+ help
+ Enable mitigation for RETBleed (Arbitrary Speculative Code Execution
+ with Return Instructions) vulnerability. RETBleed is a speculative
+ execution attack which takes advantage of microarchitectural behavior
+ in many modern microprocessors, similar to Spectre v2. An
+ unprivileged attacker can use these flaws to bypass conventional
+ memory security restrictions to gain read access to privileged memory
+ that would otherwise be inaccessible.
+
+config MITIGATION_SPECTRE_V1
+ bool "Mitigate SPECTRE V1 hardware bug"
+ default y
+ help
+ Enable mitigation for Spectre V1 (Bounds Check Bypass). Spectre V1 is a
+ class of side channel attacks that takes advantage of speculative
+ execution that bypasses conditional branch instructions used for
+ memory access bounds check.
+
+config MITIGATION_SPECTRE_V2
+ bool "Mitigate SPECTRE V2 hardware bug"
+ default y
+ help
+ Enable mitigation for Spectre V2 (Branch Target Injection). Spectre
+ V2 is a class of side channel attacks that takes advantage of
+ indirect branch predictors inside the processor. In Spectre variant 2
+ attacks, the attacker can steer speculative indirect branches in the
+ victim to gadget code by poisoning the branch target buffer of a CPU
+ used for predicting indirect branch addresses.
+
+config MITIGATION_SRBDS
+ bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
+ depends on CPU_SUP_INTEL
+ default y
+ help
+ Enable mitigation for Special Register Buffer Data Sampling (SRBDS).
+ SRBDS is a hardware vulnerability that allows Microarchitectural Data
+ Sampling (MDS) techniques to infer values returned from special
+ register accesses. An unprivileged user can extract values returned
+ from RDRAND and RDSEED executed on another core or sibling thread
+ using MDS techniques.
+
+config MITIGATION_SSB
+ bool "Mitigate Speculative Store Bypass (SSB) hardware bug"
+ default y
+ help
+ Enable mitigation for Speculative Store Bypass (SSB). SSB is a
+ hardware security vulnerability and its exploitation takes advantage
+ of speculative execution in a similar way to the Meltdown and Spectre
+ security vulnerabilities.
+
endif
config ARCH_HAS_ADD_PAGES
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 0172bb0f61fe..11ccbadd8800 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -232,7 +232,8 @@ static void x86_amd_ssb_disable(void)
#define pr_fmt(fmt) "MDS: " fmt
/* Default mitigation for MDS-affected CPUs */
-static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL;
+static enum mds_mitigations mds_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_MDS) ? MDS_MITIGATION_FULL : MDS_MITIGATION_OFF;
static bool mds_nosmt __ro_after_init = false;
static const char * const mds_strings[] = {
@@ -292,7 +293,8 @@ enum taa_mitigations {
};
/* Default mitigation for TAA-affected CPUs */
-static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_VERW;
+static enum taa_mitigations taa_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_TAA) ? TAA_MITIGATION_VERW : TAA_MITIGATION_OFF;
static bool taa_nosmt __ro_after_init;
static const char * const taa_strings[] = {
@@ -393,7 +395,8 @@ enum mmio_mitigations {
};
/* Default mitigation for Processor MMIO Stale Data vulnerabilities */
-static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_VERW;
+static enum mmio_mitigations mmio_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_MMIO_STALE_DATA) ? MMIO_MITIGATION_VERW : MMIO_MITIGATION_OFF;
static bool mmio_nosmt __ro_after_init = false;
static const char * const mmio_strings[] = {
@@ -542,7 +545,8 @@ enum srbds_mitigations {
SRBDS_MITIGATION_HYPERVISOR,
};
-static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+static enum srbds_mitigations srbds_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_SRBDS) ? SRBDS_MITIGATION_FULL : SRBDS_MITIGATION_OFF;
static const char * const srbds_strings[] = {
[SRBDS_MITIGATION_OFF] = "Vulnerable",
@@ -812,7 +816,8 @@ enum spectre_v1_mitigation {
};
static enum spectre_v1_mitigation spectre_v1_mitigation __ro_after_init =
- SPECTRE_V1_MITIGATION_AUTO;
+ IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V1) ?
+ SPECTRE_V1_MITIGATION_AUTO : SPECTRE_V1_MITIGATION_NONE;
static const char * const spectre_v1_strings[] = {
[SPECTRE_V1_MITIGATION_NONE] = "Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers",
@@ -927,7 +932,7 @@ static const char * const retbleed_strings[] = {
static enum retbleed_mitigation retbleed_mitigation __ro_after_init =
RETBLEED_MITIGATION_NONE;
static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init =
- RETBLEED_CMD_AUTO;
+ IS_ENABLED(CONFIG_MITIGATION_RETBLEED) ? RETBLEED_CMD_AUTO : RETBLEED_CMD_OFF;
static int __ro_after_init retbleed_nosmt = false;
@@ -1388,17 +1393,18 @@ static void __init spec_v2_print_cond(const char *reason, bool secure)
static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
{
- enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
+ enum spectre_v2_mitigation_cmd cmd;
char arg[20];
int ret, i;
+ cmd = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_CMD_AUTO : SPECTRE_V2_CMD_NONE;
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
cpu_mitigations_off())
return SPECTRE_V2_CMD_NONE;
ret = cmdline_find_option(boot_command_line, "spectre_v2", arg, sizeof(arg));
if (ret < 0)
- return SPECTRE_V2_CMD_AUTO;
+ return cmd;
for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
if (!match_option(arg, ret, mitigation_options[i].option))
@@ -1408,8 +1414,8 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
}
if (i >= ARRAY_SIZE(mitigation_options)) {
- pr_err("unknown option (%s). Switching to AUTO select\n", arg);
- return SPECTRE_V2_CMD_AUTO;
+ pr_err("unknown option (%s). Switching to default mode\n", arg);
+ return cmd;
}
if ((cmd == SPECTRE_V2_CMD_RETPOLINE ||
@@ -1882,10 +1888,12 @@ static const struct {
static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
{
- enum ssb_mitigation_cmd cmd = SPEC_STORE_BYPASS_CMD_AUTO;
+ enum ssb_mitigation_cmd cmd;
char arg[20];
int ret, i;
+ cmd = IS_ENABLED(CONFIG_MITIGATION_SSB) ?
+ SPEC_STORE_BYPASS_CMD_AUTO : SPEC_STORE_BYPASS_CMD_NONE;
if (cmdline_find_option_bool(boot_command_line, "nospec_store_bypass_disable") ||
cpu_mitigations_off()) {
return SPEC_STORE_BYPASS_CMD_NONE;
@@ -1893,7 +1901,7 @@ static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
ret = cmdline_find_option(boot_command_line, "spec_store_bypass_disable",
arg, sizeof(arg));
if (ret < 0)
- return SPEC_STORE_BYPASS_CMD_AUTO;
+ return cmd;
for (i = 0; i < ARRAY_SIZE(ssb_mitigation_options); i++) {
if (!match_option(arg, ret, ssb_mitigation_options[i].option))
@@ -1904,8 +1912,8 @@ static enum ssb_mitigation_cmd __init ssb_parse_cmdline(void)
}
if (i >= ARRAY_SIZE(ssb_mitigation_options)) {
- pr_err("unknown option (%s). Switching to AUTO select\n", arg);
- return SPEC_STORE_BYPASS_CMD_AUTO;
+ pr_err("unknown option (%s). Switching to default mode\n", arg);
+ return cmd;
}
}
@@ -2232,7 +2240,8 @@ EXPORT_SYMBOL_GPL(itlb_multihit_kvm_mitigation);
#define pr_fmt(fmt) "L1TF: " fmt
/* Default mitigation for L1TF-affected CPUs */
-enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_FLUSH;
+enum l1tf_mitigations l1tf_mitigation __ro_after_init =
+ IS_ENABLED(CONFIG_MITIGATION_L1TF) ? L1TF_MITIGATION_FLUSH : L1TF_MITIGATION_OFF;
#if IS_ENABLED(CONFIG_KVM_INTEL)
EXPORT_SYMBOL_GPL(l1tf_mitigation);
#endif
--
2.34.1
On Thu, Oct 19, 2023 at 11:11:58AM -0700, Breno Leitao wrote:
> Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> where some mitigations have entries in Kconfig, and they could be
> modified, while others mitigations do not have Kconfig entries, and
> could not be controlled at build time.
>
> Create an entry for each CPU mitigation under
> CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
> them at compilation time.
>
> Signed-off-by: Breno Leitao <[email protected]>
We also probably need a CONFIG_MITIGATION_MELTDOWN.
> ---
> arch/x86/Kconfig | 93 ++++++++++++++++++++++++++++++++++++++
> arch/x86/kernel/cpu/bugs.c | 39 ++++++++++------
> 2 files changed, 117 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a5cada7443ea..ccdcb1dcdc0c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2591,6 +2591,99 @@ config MITIGATION_GDS_FORCE
>
> If in doubt, say N.
>
> +config MITIGATION_MDS
> + bool "Mitigate Microarchitectural Data Sampling (MDS) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for Microarchitectural Data Sampling (MDS). MDS is
> + a hardware vulnerability which allows unprivileged speculative access
> + to data which is available in various CPU internal buffer. Deeper
buffers
> + technical information is available in the MDS specific x86 architecture
> + section: Documentation/arch/x86/mds.rst.
I believe the high-level document is actually
Documentation/admin-guide/hw-vuln/mds.rst.
> +config MITIGATION_TAA
> + bool "Mitigate TSX Asynchronous Abort (TAA) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for TSX Asynchronous Abort (TAA). TAA is a hardware
> + vulnerability that allows unprivileged speculative access to data
> + which is available in various CPU internal buffers by using
> + asynchronous aborts within an Intel TSX transactional region.
Refer to Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
> +config MITIGATION_MMIO_STALE_DATA
> + bool "Mitigate MMIO Stale Data hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for MMIO Stale Data hardware bugs. Processor MMIO
> + Stale Data Vulnerabilities are a class of memory-mapped I/O (MMIO)
> + vulnerabilities that can expose data. The vulnerabilities require the
> + attacker to have access to MMIO.
Refer to Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
> +config MITIGATION_L1TF
> + bool "Mitigate L1 Terminal Fault (L1TF) hardware bug"
depends on CPU_SUP_INTEL
> + default y
> + help
> + Mitigate L1 Terminal Fault (L1TF) hardware bug. L1 Terminal Fault is a
> + hardware vulnerability which allows unprivileged speculative access to data
> + which is available in the Level 1 Data Cache when the page table
> + entry controlling the virtual address.
-EGRAMMAR
Also refer to Documentation/admin-guide/hw-vuln/l1tf.rst
> +config MITIGATION_RETBLEED
> + bool "Mitigate RETBleed hardware bug"
depends on CPU_SUP_INTEL || (CPU_SUP_AMD && MITIGATION_UNRET_ENTRY)
> +config MITIGATION_SPECTRE_V1
> + bool "Mitigate SPECTRE V1 hardware bug"
> + default y
> + help
> + Enable mitigation for Spectre V1 (Bounds Check Bypass). Spectre V1 is a
> + class of side channel attacks that takes advantage of speculative
> + execution that bypasses conditional branch instructions used for
> + memory access bounds check.
Refer to Documentation/admin-guide/hw-vuln/spectre.rst
> +config MITIGATION_SPECTRE_V2
> + bool "Mitigate SPECTRE V2 hardware bug"
> + default y
> + help
> + Enable mitigation for Spectre V2 (Branch Target Injection). Spectre
> + V2 is a class of side channel attacks that takes advantage of
> + indirect branch predictors inside the processor. In Spectre variant 2
> + attacks, the attacker can steer speculative indirect branches in the
> + victim to gadget code by poisoning the branch target buffer of a CPU
> + used for predicting indirect branch addresses.
Refer to Documentation/admin-guide/hw-vuln/spectre.rst
> +config MITIGATION_SRBDS
> + bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
> + depends on CPU_SUP_INTEL
> + default y
> + help
> + Enable mitigation for Special Register Buffer Data Sampling (SRBDS).
> + SRBDS is a hardware vulnerability that allows Microarchitectural Data
> + Sampling (MDS) techniques to infer values returned from special
> + register accesses. An unprivileged user can extract values returned
> + from RDRAND and RDSEED executed on another core or sibling thread
> + using MDS techniques.
Refer to Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
> + cmd = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_CMD_AUTO : SPECTRE_V2_CMD_NONE;
> if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
> cpu_mitigations_off())
> return SPECTRE_V2_CMD_NONE;
I'm thinking CONFIG_MITIGATION_SPECTRE_V2 should also affect whether the spectre v2 user
mitigation gets enabled.
--
Josh
Hello Josh,
On Wed, Oct 25, 2023 at 09:29:06AM -0700, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2023 at 11:11:58AM -0700, Breno Leitao wrote:
> > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> > where some mitigations have entries in Kconfig, and they could be
> > modified, while others mitigations do not have Kconfig entries, and
> > could not be controlled at build time.
> >
> > Create an entry for each CPU mitigation under
> > CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
> > them at compilation time.
> >
> > Signed-off-by: Breno Leitao <[email protected]>
>
> We also probably need a CONFIG_MITIGATION_MELTDOWN.
Isn't Meltdown covered by the MITIGATION_PAGE_TABLE_ISOLATION Kconfig
entry? Would you mind clarifying what would be the difference between
CONFIG_MITIGATION_MELTDOWN and MITIGATION_PAGE_TABLE_ISOLATION, and why
do we want CONFIG_MITIGATION_MELTDOWN?
> > ---
> > arch/x86/Kconfig | 93 ++++++++++++++++++++++++++++++++++++++
> > arch/x86/kernel/cpu/bugs.c | 39 ++++++++++------
> > 2 files changed, 117 insertions(+), 15 deletions(-)
<snip>
> > +config MITIGATION_SRBDS
> > + bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
> > + depends on CPU_SUP_INTEL
> > + default y
> > + help
> > + Enable mitigation for Special Register Buffer Data Sampling (SRBDS).
> > + SRBDS is a hardware vulnerability that allows Microarchitectural Data
> > + Sampling (MDS) techniques to infer values returned from special
> > + register accesses. An unprivileged user can extract values returned
> > + from RDRAND and RDSEED executed on another core or sibling thread
> > + using MDS techniques.
>
> Refer to Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
Sure, I will update this and all the other suggestions that were cut
above. Thanks!
> > + cmd = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_CMD_AUTO : SPECTRE_V2_CMD_NONE;
> > if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
> > cpu_mitigations_off())
> > return SPECTRE_V2_CMD_NONE;
>
> I'm thinking CONFIG_MITIGATION_SPECTRE_V2 should also affect whether the spectre v2 user
> mitigation gets enabled.
Makes sense, would something like this be enough?
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 11ccbadd8800..cfcdbfa72a81 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1221,8 +1221,10 @@ static __ro_after_init enum spectre_v2_mitigation_cmd spectre_v2_cmd;
static enum spectre_v2_user_cmd __init
spectre_v2_parse_user_cmdline(void)
{
+ int ret, i, mode;
char arg[20];
- int ret, i;
+
+ mode = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_USER_CMD_AUTO : SPECTRE_V2_USER_CMD_NONE;
switch (spectre_v2_cmd) {
case SPECTRE_V2_CMD_NONE:
@@ -1236,7 +1238,7 @@ spectre_v2_parse_user_cmdline(void)
ret = cmdline_find_option(boot_command_line, "spectre_v2_user",
arg, sizeof(arg));
if (ret < 0)
- return SPECTRE_V2_USER_CMD_AUTO;
+ return mode;
for (i = 0; i < ARRAY_SIZE(v2_user_options); i++) {
if (match_option(arg, ret, v2_user_options[i].option)) {
@@ -1246,8 +1248,8 @@ spectre_v2_parse_user_cmdline(void)
}
}
- pr_err("Unknown user space protection option (%s). Switching to AUTO select\n", arg);
- return SPECTRE_V2_USER_CMD_AUTO;
+ pr_err("Unknown user space protection option (%s). Switching to default\n", arg);
+ return mode;
}
On Thu, Nov 09, 2023 at 02:43:56PM -0800, Josh Poimboeuf wrote:
> On Thu, Oct 26, 2023 at 10:09:17AM -0700, Breno Leitao wrote:
> > > I'm thinking CONFIG_MITIGATION_SPECTRE_V2 should also affect whether the spectre v2 user
> > > mitigation gets enabled.
> >
> > Makes sense, would something like this be enough?
>
> Looks good to me.
>
> While you're at it, for consistency can you add a cpu_mitigations_off()
> check to spectre_v2_parse_user_cmdline()?
Good catch. I think we might want to do it in
`spectre_v2_user_select_mitigation()`, but let me test better and send it.
Since this is not dependent on this patch series, I will send this as an
idividual patch, to avoiding growing this patchset much (currently at 13
patches).
Thanks