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: <ZRwZOtANkcwtL+5B@gmail.com>
Date:   Tue, 3 Oct 2023 15:38:02 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>, 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


* Uros Bizjak <ubizjak@...il.com> wrote:

> > Maybe, but Linus's reluctance and caution is justified IMHO, and at 
> > minimum this feature needs some careful evaluation of long-time 
> > suitability [*] ...
> 
> I do have a proposal on how to introduce a new feature while minimising 
> risk as much as possible. I must admit that detecting the feature for all 
> released compilers that can handle __seg_gs seems quite risky (I have to 
> curb my enthusiasm somehow ;) ), so perhaps a staged approach with a 
> currently unreleased compiler is more appropriate. Using:
> 
> +config CC_HAS_NAMED_AS
> +       def_bool CC_IS_GCC && GCC_VERSION >= 140000
> 
> would enable the new feature only for currently unreleased experimental 
> GCC. This would allow to qualify the compiler and weed out any possible 
> problems, before the compiler is released. Please note, that the patch is 
> written in such a way, that the code reverts to the existing approach for 
> undefined CC_HAS_NAMED_AS.

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

Instead, if Linus doesn't disagree that is, how about restricting it to the 
freshest GCC minor version? Ie. GCC 13.1 and later. We could carry it in a 
separate branch in -tip for a while and not merge it into v6.7 but v6.8 or 
so.

That would at least give us *some* amount of test coverage, without any 
real upstream risk.

Thanks,

	Ingo