linux-kernel - Re: [PATCH] READ_ONCE, WRITE_ONCE, kcsan: Perform checks in __*

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]

Date:   Wed, 20 May 2020 00:05:08 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Qian Cai <cai@....pw>, Marco Elver <elver@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Will Deacon <will@...nel.org>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] READ_ONCE, WRITE_ONCE, kcsan: Perform checks in __*_ONCE variants

Qian Cai <cai@....pw> writes:
> On Tue, May 19, 2020 at 5:26 PM Marco Elver <elver@...gle.com> wrote:
>> The new solution is here:
>>     https://lkml.kernel.org/r/20200515150338.190344-1-elver@google.com
>> While it's a little inconvenient that we'll require Clang 11
>> (currently available by building yourself from LLVM repo), but until
>> we get GCC fixed (my patch there still pending :-/), this is probably
>> the right solution going forward.   If possible, please do test!
>
> That would be quite unfortunate. The version here is still gcc-8.3.1
> and clang-9.0.1 on RHEL 8.2 here. It will probably need many years to
> be able to get the fixed compilers having versions that high. Sigh...
> Also, I want to avoid compiling compilers on my own.

Yes, it's unfortunate, but we have to stop making major concessions just
because tools are not up to the task.

We've done that way too much in the past and this particular problem
clearly demonstrates that there are limits.

Making brand new technology depend on sane tools is not asked too
much. And yes, it's inconvenient, but all of us have to build tools
every now and then to get our job done. It's not the end of the world.

Building clang is trivial enough and pointing the make to the right
compiler is not rocket science either.

Thanks,

        tglx