Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to avoid userspace regression

[Thomas Gleixner]

On Wed, Sep 28 2022 at 17:56, Guilherme G. Piccoli wrote:
> On 28/09/2022 17:24, Luck, Tony wrote:
>> [...] 
>> Why not just use the workaround suggested in that bug report:
>> 
>>    "so manual switching from default setting to split_lock_detect=off helps as workaround here"
>> 
>> If you add this extra mode, I'm going to argue that the kernel default
>> should be "seq" rather than "warn". So these game players will need
>> to add a split_lock_detect=off (or warn) option.
>> 
>
> Hi Tony, thanks for your response. The workaround is the way to
> circumvent the issue for now, but not all users want (or know how) to
> deal with the kernel parameters. If a distro wants to default to show a
> warning only, but don't break performance so hard, this would be
> currently impossible.

That Kconfig knob is patently bad. The only sane choice for a generic
distro kernel is to slow down the offenders simply because split lock is
a trivial unpriviledged DoS. Run a split locker in a tight loop and
watch your shiny new multicore system degrading into a machine from the
80s. So unless the distro provides a "special broken games" kernel the
users will still need to fiddle with the command line.

Attack vector prevention has precedence over broken applications. That's what
command line options or sysctls are for.

> The main/big issues here are two: defaulting to the disruptive behavior
> (with no way of building a kernel not defaulting to that without
> patching), and not having a way to warn about split locking without
> breaking the performance, hence the new mode "seq".

Which is a misnomer and tells absolutely nothing. If we add a new
parameter then we name it something like "mitigate" and make it the
default.

But a way better solution is to add a sysctl knob which allows to
disable the slowdown mechanics and that allows distros to give the user
an trivial knob in the GUI to switch to "I don't care. My broken game is
more important!" mode, while still maintaining the only sensible default
of preventing damage for the general use case of the generic distro
kernel.

Thanks,

        tglx