| Message ID | f0bd17358ab478eaca52f3b1da8305c150911b40.1554396090.git.jpoimboe@redhat.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
| Series | cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options | expand |
On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote: > 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 > their own custom way to mitigate the same vulnerability. ... tends to _have_ its own custom way ...
On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote: > 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 > their own custom way to mitigate the same vulnerability. Yap, we definitely need something like that. > 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 Uff, "reasonable" - there's the bikeshed waiting to happen. > 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: > > - cpu_spec_mitigations=off: Disable all mitigations. "cpu_spec_mitigations" is too long, TBH. Imagine yourself in a loud, noisy data center - you basically can't wait to leave - crouched over a keyboard in an impossible position, having to type that thing and then making a typo. Whoops, too late, already pressed Enter. Shiiiit! Now you have to wait at least 15 mins for the damn single-threaded added value BIOS crap to noodle through all the cores just so you can try again, because you just rebooted the box. And I know, my ideas for shorter cmdline options are crazy, like cpu_spec_mtg= which people would say, yuck, unreadable... Oh, I know! How about cpu_vulns= ? We already have /sys/devices/system/cpu/vulnerabilities so it'll be the same as that. Less things to remember. > - cpu_spec_mitigations=auto: [default] Enable all the default > mitigations, but leave SMT enabled, even if it's vulnerable. > > - cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations, > disabling SMT if needed by a mitigation. Yah, the suboption choices make sense to me. > > 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> > --- > .../admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++ > include/linux/cpu.h | 8 +++++++ > kernel/cpu.c | 15 ++++++++++++ > 3 files changed, 46 insertions(+) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index c4d830003b21..ac42e510bd6e 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -2544,6 +2544,29 @@ > in the "bleeding edge" mini2440 support kernel at > http://repo.or.cz/w/linux-2.6/mini2440.git > > + cpu_spec_mitigations= > + [KNL] Control mitigations for CPU speculation > + vulnerabilities on affected CPUs. This is a set of > + curated, arch-independent options, each of which is an > + aggregation of existing options. > + > + off > + Disable all speculative CPU mitigations. Alias to cpu_vulns=make_linux_fast_again :-P
On Fri, Apr 05, 2019 at 03:12:11PM +0200, Borislav Petkov wrote: > On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote: > > 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 > > their own custom way to mitigate the same vulnerability. > > Yap, we definitely need something like that. > > > 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 > > Uff, "reasonable" - there's the bikeshed waiting to happen. Luckily the defaults have already been chosen. So "reasonable" just means to use the defaults. > > 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: > > > > - cpu_spec_mitigations=off: Disable all mitigations. > > "cpu_spec_mitigations" is too long, TBH. > > Imagine yourself in a loud, noisy data center - you basically can't wait > to leave - crouched over a keyboard in an impossible position, having > to type that thing and then making a typo. Whoops, too late, already > pressed Enter. Shiiiit! Sure, it's a bit long. But it's also easier to remember and more self-documenting than any shortened option I could come up with. In your scenario, the fact that it's so easy to remember would save the day, since you wouldn't have to go look up some obscure shortened option name in the documentation :-) Suggestions are welcome but I couldn't come up with a reasonable shorter option. > Now you have to wait at least 15 mins for the damn single-threaded added > value BIOS crap to noodle through all the cores just so you can try > again, because you just rebooted the box. > > And I know, my ideas for shorter cmdline options are crazy, like > > cpu_spec_mtg= > > which people would say, yuck, unreadable... I agree with those people. In my world "mtg" is short for meeting. > Oh, I know! How about > > cpu_vulns= > > ? No, because a) We aren't enabling/disabling *vulnerabilities*, but rather mitigations; b) We aren't enabling/disabling *all* CPU mitigations, only the speculative ones. > We already have /sys/devices/system/cpu/vulnerabilities so it'll be the > same as that. Less things to remember. Except that it's not called "cpu_vulns"...
On Fri, Apr 05, 2019 at 09:20:48AM -0500, Josh Poimboeuf wrote: > In your scenario, the fact that it's so easy to remember would save the > day, since you wouldn't have to go look up some obscure shortened option > name in the documentation :-) No no, the idea is for the short option to be memorable. > Suggestions are welcome but I couldn't come up with a reasonable shorter > option. Same here.
Thinking about this more, we can shave off the first 4 chars and have it be: spec_mitigations= I think it is painfully clear which speculation mitigations we mean. And the other switches don't have "cpu_" prefixes too so...
On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: > Thinking about this more, we can shave off the first 4 chars and have it > be: > > spec_mitigations= > > I think it is painfully clear which speculation mitigations we mean. And > the other switches don't have "cpu_" prefixes too so... Sure, I'm ok with renaming it to that, if there are no objections.
Josh Poimboeuf <jpoimboe@redhat.com> writes: > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: >> Thinking about this more, we can shave off the first 4 chars and have it >> be: >> >> spec_mitigations= >> >> I think it is painfully clear which speculation mitigations we mean. And >> the other switches don't have "cpu_" prefixes too so... > > Sure, I'm ok with renaming it to that, if there are no objections. What about when we have a mitigation for a non-speculation related bug :) mitigations=xxx ? cheers
On Wed, Apr 10, 2019 at 03:48:48PM +1000, Michael Ellerman wrote:
> What about when we have a mitigation for a non-speculation related bug :)
Like that is *ever* going to happen... :-P
On Wed, 10 Apr 2019, Michael Ellerman wrote: > Josh Poimboeuf <jpoimboe@redhat.com> writes: > > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: > >> Thinking about this more, we can shave off the first 4 chars and have it > >> be: > >> > >> spec_mitigations= > >> > >> I think it is painfully clear which speculation mitigations we mean. And > >> the other switches don't have "cpu_" prefixes too so... > > > > Sure, I'm ok with renaming it to that, if there are no objections. > > What about when we have a mitigation for a non-speculation related bug :) Those kind of silicon bugs are usually mitigated unconditionally. Thanks, tglx
On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote: > On Wed, 10 Apr 2019, Michael Ellerman wrote: > > Josh Poimboeuf <jpoimboe@redhat.com> writes: > > > > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: > > >> Thinking about this more, we can shave off the first 4 chars and have it > > >> be: > > >> > > >> spec_mitigations= > > >> > > >> I think it is painfully clear which speculation mitigations we mean. And > > >> the other switches don't have "cpu_" prefixes too so... > > > > > > Sure, I'm ok with renaming it to that, if there are no objections. > > > > What about when we have a mitigation for a non-speculation related bug :) > > Those kind of silicon bugs are usually mitigated unconditionally. Right. But at least "mitigations=" is nice and short. We could clarify in the documentation that it doesn't apply to *all* mitigations, only the ones which are optional and which can affect performance. And it would give us the freedom to include any future "optional" mitigations, spec or not. I kind of like it. But I could go either way.
Thomas Gleixner <tglx@linutronix.de> writes: > On Wed, 10 Apr 2019, Michael Ellerman wrote: >> Josh Poimboeuf <jpoimboe@redhat.com> writes: >> >> > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: >> >> Thinking about this more, we can shave off the first 4 chars and have it >> >> be: >> >> >> >> spec_mitigations= >> >> >> >> I think it is painfully clear which speculation mitigations we mean. And >> >> the other switches don't have "cpu_" prefixes too so... >> > >> > Sure, I'm ok with renaming it to that, if there are no objections. >> >> What about when we have a mitigation for a non-speculation related bug :) > > Those kind of silicon bugs are usually mitigated unconditionally. I guess that's true, usually :) cheers
Josh Poimboeuf <jpoimboe@redhat.com> writes: > On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote: >> On Wed, 10 Apr 2019, Michael Ellerman wrote: >> > Josh Poimboeuf <jpoimboe@redhat.com> writes: >> > >> > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: >> > >> Thinking about this more, we can shave off the first 4 chars and have it >> > >> be: >> > >> >> > >> spec_mitigations= >> > >> >> > >> I think it is painfully clear which speculation mitigations we mean. And >> > >> the other switches don't have "cpu_" prefixes too so... >> > > >> > > Sure, I'm ok with renaming it to that, if there are no objections. >> > >> > What about when we have a mitigation for a non-speculation related bug :) >> >> Those kind of silicon bugs are usually mitigated unconditionally. > > Right. > > But at least "mitigations=" is nice and short. We could clarify in the > documentation that it doesn't apply to *all* mitigations, only the ones > which are optional and which can affect performance. > > And it would give us the freedom to include any future "optional" > mitigations, spec or not. > > I kind of like it. But I could go either way. Some of the published SMT attacks are not speculation based. And arguably we already have an optional mitigation for those, ie. nosmt. cheers
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c4d830003b21..ac42e510bd6e 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2544,6 +2544,29 @@ in the "bleeding edge" mini2440 support kernel at http://repo.or.cz/w/linux-2.6/mini2440.git + cpu_spec_mitigations= + [KNL] Control mitigations for CPU speculation + vulnerabilities on affected CPUs. This is a set of + curated, arch-independent options, each of which is an + aggregation of existing options. + + off + Disable all speculative CPU mitigations. + + auto (default) + Mitigate all speculative CPU vulnerabilities, + but leave SMT enabled, even if it's vulnerable. + This is useful for users who don't want to be + surprised by SMT getting disabled across kernel + upgrades, or who have other ways of avoiding + SMT-based attacks. + + auto,nosmt + Mitigate all speculative CPU vulnerabilities, + disabling SMT if needed. This is for users who + always want to be fully mitigated, even if it + means losing SMT. + mminit_loglevel= [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this parameter allows control of the logging verbosity for diff --git a/include/linux/cpu.h b/include/linux/cpu.h index 5041357d0297..3a1740fda2e2 100644 --- a/include/linux/cpu.h +++ b/include/linux/cpu.h @@ -187,4 +187,12 @@ static inline void cpu_smt_disable(bool force) { } static inline void cpu_smt_check_topology(void) { } #endif +enum cpu_spec_mitigations { + CPU_SPEC_MITIGATIONS_OFF, + CPU_SPEC_MITIGATIONS_AUTO, + CPU_SPEC_MITIGATIONS_AUTO_NOSMT, +}; + +extern enum cpu_spec_mitigations cpu_spec_mitigations; + #endif /* _LINUX_CPU_H_ */ diff --git a/kernel/cpu.c b/kernel/cpu.c index 6c959aea0f9e..0a9d66b90a00 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -2306,3 +2306,18 @@ void __init boot_cpu_hotplug_init(void) #endif this_cpu_write(cpuhp_state.state, CPUHP_ONLINE); } + +enum cpu_spec_mitigations cpu_spec_mitigations __ro_after_init = CPU_SPEC_MITIGATIONS_AUTO; + +static int __init cpu_spec_mitigations_setup(char *arg) +{ + if (!strcmp(arg, "off")) + cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_OFF; + else if (!strcmp(arg, "auto")) + cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO; + else if (!strcmp(arg, "auto,nosmt")) + cpu_spec_mitigations = CPU_SPEC_MITIGATIONS_AUTO_NOSMT; + + return 0; +} +early_param("cpu_spec_mitigations", cpu_spec_mitigations_setup);
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 their 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: - cpu_spec_mitigations=off: Disable all mitigations. - cpu_spec_mitigations=auto: [default] Enable all the default mitigations, but leave SMT enabled, even if it's vulnerable. - cpu_spec_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> --- .../admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++ include/linux/cpu.h | 8 +++++++ kernel/cpu.c | 15 ++++++++++++ 3 files changed, 46 insertions(+)