linux-kernel - Re: [PATCH] gcov,x86: Mark GCOV broken for x86

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: <20210614162018.GD68749@worktop.programming.kicks-ass.net>
Date:   Mon, 14 Jun 2021 18:20:18 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Johannes Berg <johannes.berg@...el.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Marco Elver <elver@...gle.com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] gcov,x86: Mark GCOV broken for x86

On Mon, Jun 14, 2021 at 09:05:04AM -0700, Nick Desaulniers wrote:
> On Mon, Jun 14, 2021 at 3:17 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >
> > As recently discovered, there is no function attribute to disable the
> > -fprofile-generate instrumentation. As such, GCOV is fundamentally
> > incompatible with architectures that rely on 'noinstr' for correctness.
> 
> Is there context for comment, or is this patch meant as a joke?

Only if you think recursion in exception entry code is funny.

noinstr *MUST* disable any and all compiler generated instrumentation,
currently it that isn't the case for -fprofile-gnerate, nor
-fprofile-arc.

Look for all the fun we had with KCOV back then. Luckily KCOV
instrumentation was trivial to patch out using objtool, so that's what
x86 is currently doing.

Luckily both compilers grew a __no_sanitize_coverage recently and we no
longer have to rely on objtool fixing up the compiler output for much
longer.

  https://lkml.kernel.org/r/20210527194448.3470080-1-elver@google.com

Now all we need is one more such attribute to kill -fprofile-* stuff.