Messages in this thread Patch in this message | | | Date | Thu, 26 Oct 2023 10:09:17 -0700 | From | Breno Leitao <> | Subject | Re: [PATCH v5 12/12] x86/bugs: Add a separate config for missing mitigation |
| |
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 <leitao@debian.org> > > 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; }
| |