linux-kernel - Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers

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:   Tue, 3 Oct 2023 12:31:33 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Uros Bizjak <ubizjak@...il.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        Nadav Amit <namit@...are.com>, Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers

On Tue, 3 Oct 2023 at 06:38, Ingo Molnar <mingo@...nel.org> wrote:
>
> So I don't think it's a good idea to restrict it to the devel GCC version
> only, the cross-section of devel-GCC and devel-kernel reduces testing
> coverage to near-zero in practice ...

In fact, while the clang failure was arguably worse from a code
generation standpoint (as in "it didn't generate any code AT ALL"), it
was actually better from a kernel standpoint: I'd *much* rather have a
compile-time failure than bad code generation when it's a particular
issue that we can avoid by just not doing it.

IOW, *if* this is the only actual issue with named address spaces,
then I'd much rather have a compiler that says "don't do that" over a
compiler that silently generates absolutely horrendous code.

That is not unlike my "I'd rather get a link time error from trying to
do a 64-by-64 divide on x86-32, than have the compiler actually
generate that horrendously expensive operation". There's a reason we
have "do_div64()" to do 64-by-32 divides, because that's usually what
you actually want.

We should not be doing big structure copies from or to the percpu
area, so clang then failing with an admittedly horrendous error
message is not a bad thing.

And again - my worry really isn't this "copy a percpu structure"
issue. It's literally just that I feel this doesn't have a lot of
coverage.

              Linus