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]

Message-ID: <ZRxu9+ZJqjY/u8ku@gmail.com>
Date:   Tue, 3 Oct 2023 21:43:51 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

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

I share all those concerns.

So we could do this: we let it live in -tip for a cycle, in a separate
branch, and observe what happens - it gets picked up by -next on
a daily basis and most x86 developers test it. It won't be merged by other
branches in -tip, it won't be pulled by others or relied on. If it
conflicts with other bits we rebase it cleanly, no questions asked.

While -next test coverage is still limited in many ways, it's also
certainly not zero.

If it's problem-free for a cycle I'll offer it up to you as an RFC pull,
summarizing our experience with it. (Should it ever get to that point.)

That's the best I think we can do - and worst-case we'll turn it off
again and go curse flaky compiler features. Will be easy to turn off
if it's compiler version triggered anyway.

Thanks,

	Ingo