linux-kernel - Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

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: <aUPsdDY09Jzn3ILf@gate>
Date: Thu, 18 Dec 2025 05:58:44 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Marco Elver <elver@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ard Biesheuvel <ardb@...nel.org>,
        Kees Cook <kees@...nel.org>, Brendan Jackman <jackmanb@...gle.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
        linux-toolchains@...r.kernel.org
Subject: Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

Hi!

On Thu, Dec 18, 2025 at 10:56:48AM +0100, Marco Elver wrote:
> On Thu, 18 Dec 2025 at 10:51, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Sat, Dec 13, 2025 at 08:59:44AM +0900, Ard Biesheuvel wrote:
> >
> > > > After that I sat down and finally got around to implement the builtin
> > > > that should solve this once and for all, regardless of where it's
> > > > called: https://github.com/llvm/llvm-project/pull/172030
> > > > What this will allow us to do is to remove the
> > > > "K[AC]SAN_SANITIZE_noinstr.o := n" lines from the Makefile, and purely
> > > > rely on the noinstr attribute, even in the presence of explicit
> > > > instrumentation calls.
> > > >
> > >
> > > Excellent! Thanks for the quick fix. Happy to test and/or look into
> > > the kernel side of this once this lands.
> >
> > Well, would not GCC need to grow the same thing and then we must wait
> > until these versions are the minimum supported versions for sanitizer
> > builds.
> >
> > I mean, the extension is nice, but I'm afraid we can't really use it
> > until much later :/
> 
> Unfortunately, yes. But let's try to get the builtin into Clang and
> GCC now (for the latter, need to Cc GCC folks to help).
> 
> Then we wait for 5 years. :-)
> 
> There's a possibility to try and backport it to stable Clang and GCC
> versions, but it's a long stretch (extremely unlikely).

We (GCC) do not generally want to do backport features; even for
bugfixes the risk/reward ratio comes into the picture.  It *can* be done
if some feature is important enough of course.  If you have to wonder or
ask if your feature is important enough, it is not.

The reason we do not want backports of feature is it increases
maintenance cost a lot, and so, development costs as well.

I guess LLVM has a similar policy, but I of course do not speak for
them.

You might have more success getting the stuff backported to some
distro(s) you care about?  Or get people to use newer compilers more
quickly of course, "five years" before people have it is pretty
ridiculous, two years is at the tail end of things already.


Segher