Hi Greg, Ben,
On Wed, May 15, 2019 at 1:12 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
From: Josh Poimboeuf jpoimboe@redhat.com
commit 98af8452945c55652de68536afdde3b520fec429 upstream.
Keeping track of the number of mitigations for all the CPU speculation bugs has become overwhelming for many users. It's getting more and more complicated to decide which mitigations are needed for a given architecture. Complicating matters is the fact that each arch tends to have its own custom way to mitigate the same vulnerability.
Most users fall into a few basic categories:
a) they want all mitigations off;
b) they want all reasonable mitigations on, with SMT enabled even if it's vulnerable; or
c) they want all reasonable mitigations on, with SMT disabled if vulnerable.
Define a set of curated, arch-independent options, each of which is an aggregation of existing options:
mitigations=off: Disable all mitigations.
mitigations=auto: [default] Enable all the default mitigations, but leave SMT enabled, even if it's vulnerable.
mitigations=auto,nosmt: Enable all the default mitigations, disabling SMT if needed by a mitigation.
Currently, these options are placeholders which don't actually do anything. They will be fleshed out in upcoming patches.
Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com Signed-off-by: Thomas Gleixner tglx@linutronix.de
[bwh: Backported to 4.4:
- Drop the auto,nosmt option which we can't support
This doesn't really stand out. I.e. I completely missed it, and started wondering why "auto,nosmt" was not documented in kernel-parameters.txt below...
--- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2173,6 +2173,25 @@ bytes respectively. Such letter suffixes in the "bleeding edge" mini2440 support kernel at http://repo.or.cz/w/linux-2.6/mini2440.git
mitigations=Control optional mitigations for CPU vulnerabilities.This is a set of curated, arch-independent options, eachof which is an aggregation of existing arch-specificoptions.offDisable all optional CPU mitigations. Thisimproves system performance, but it may alsoexpose users to several CPU vulnerabilities.auto (default)Mitigate all CPU vulnerabilities, but leave SMTenabled, even if it's vulnerable. This is forusers who don't want to be surprised by SMTgetting disabled across kernel upgrades, or whohave other ways of avoiding SMT-based attacks.This is the default behavior.mminit_loglevel= [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this parameter allows control of the logging verbosity for
--- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -842,3 +842,16 @@ void init_cpu_online(const struct cpumas { cpumask_copy(to_cpumask(cpu_online_bits), src); }
+enum cpu_mitigations cpu_mitigations = CPU_MITIGATIONS_AUTO;
+static int __init mitigations_parse_cmdline(char *arg) +{
if (!strcmp(arg, "off"))cpu_mitigations = CPU_MITIGATIONS_OFF;else if (!strcmp(arg, "auto"))cpu_mitigations = CPU_MITIGATIONS_AUTO;
Perhaps
else pr_crit("mitigations=%s is not supported\n", arg);
?
Actually that makes sense on mainline, too. Cooking a patch...
return 0;+} +early_param("mitigations", mitigations_parse_cmdline);
Gr{oetje,eeting}s,
Geert