linux-kernel - Re: [PATCH] kcov: add __no_sanitize_coverage to fix noinstr for all architectures

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:   Wed, 26 May 2021 03:53:48 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Marco Elver <elver@...gle.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Arnd Bergmann <arnd@...db.de>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] kcov: add __no_sanitize_coverage to fix noinstr for all architectures

On Tue, May 25, 2021 at 9:13 PM Marco Elver <elver@...gle.com> wrote:
>
> Long story short: this is not fixable without more Clang changes. The
> only way to do it without a version check would be to introduce
> no_sanitize_coverage attr to Clang, which we probably shouldn't do,
> and I didn't want to fight it. ;-)

I am not sure I followed why you would not want to support querying
for the attributes (if they are intended to be used separately).

But regardless of that, why not the feature flag at least then, to be
consistent with the others?

Going back to version checks seems bad -- they should be reserved for
e.g. known broken versions and things like that. New compiler features
should come with new feature flags...

In fact, for Clang, I do not see any version checks in code at the
moment, so this would be the first :(

Cheers,
Miguel