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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e11f3e5-6a16-4a7a-8e1f-470c45dac64e@codeweavers.com>
Date:   Thu, 29 Sep 2022 12:17:06 -0500
From:   Zebediah Figura <zfigura@...eweavers.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>, tony.luck@...el.com,
        tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org
Cc:     mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        hpa@...or.com, luto@...nel.org, kernel-dev@...lia.com,
        kernel@...ccoli.net, Fenghua Yu <fenghua.yu@...el.com>,
        Joshua Ashton <joshua@...ggi.es>,
        Paul Gofman <pgofman@...eweavers.com>,
        Pavel Machek <pavel@...x.de>,
        Pierre-Loup Griffais <pgriffais@...vesoftware.com>,
        Melissa Wen <mwen@...lia.com>
Subject: Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to
 avoid userspace regression

On 9/28/22 16:50, Dave Hansen wrote:
> I really don't like the idea of *both* a new boot parameter and a new
> Kconfig option.
> 
> The warning mode worked as intended in this case because it got a user
> to file a bug and that bug report made it back to us.  It's kinda funny
> to respond to that report by reducing the misery.
> 
> On the other hand, all the report resulted in was finger-pointing at a
> binary Windows applications that neither we nor probably anybody else
> can do anything about.
> 
> It boils down to either:
>   * The misery is good and we keep it as-is, or
>   * The misery is bad and we kill it
> 
> My gut says we should keep the warnings and kill the misery.  The folks
> who are going to be able to fix the issues are probably also the ones
> looking at dmesg and don't need the extra hint from the misery.  The
> folks running Windows games don't look at dmesg and just want to play
> their game without misery.

This seems like a reasonable position, but on the other hand...

> The other option is to wait and see if there's any kind of pattern with
> these reports.

...if the pattern ends up being "closed-source Windows software", as is 
not unlikely, then maybe this is something that could be made into a 
personality, that emulators like Wine could enable? I don't know how 
distasteful such optional workarounds are in general, but this would at 
least allow the original warning to continue working as intended for 
software that can be fixed.

ἔρρωσθε,
Zeb