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"... -- Josh
