linux-kernel - Re: [PATCH] compiler_types: mark __compiletime_assert failure as _

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:   Thu, 14 Oct 2021 11:55:30 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        llvm@...ts.linux.dev, Rasmus Villemoes <linux@...musvillemoes.dk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] compiler_types: mark __compiletime_assert failure as __noreturn

On Thu, Oct 14, 2021 at 11:41 AM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Thu, Oct 14, 2021 at 8:33 PM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
> >
> > That would be a nice to do, but I am not sure about introducing one
> > more macro about this... I think it would be simpler to submit patches
> > for moves into `static_assert` even if we have to "flip" the meaning.

$ grep -r BUILD_BUG_ON | wc -l
3405

> Actually, what would be ideal is a compiler-backed lint that checks
> whether it could be an `static_assert`, perhaps in clang-tidy?

Oh, that is a good idea.  There is one already for recommending the
use of static_assert instead of assert.  That's actually very nice.

I was playing with trying to adapt clang-tidy's C++11 `auto` fixit to
work on GNU C code to automate the replacement of:

__typeof(x) y = (x);

with:

__auto_type y = (x);

in macros.  That's perhaps interesting, too.  Given the volume of code
in the kernel, I wouldn't waste time with one off patches; rather I'd
work on automation (since clang-tidy can be taught "fixits" to fix the
code in place, not just warn) so that we can better enable treewide
changes AND keep new instances from sneaking back in easier.

Let's see if I get an intern in 2022, maybe I can have them focus on
clang-tidy+kernel.

>
> It would also ensure things are kept clean.
>
> Cheers,
> Miguel

-- 
Thanks,
~Nick Desaulniers