linux-kernel - Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")

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: <20220629163400.cgeqmuu45zsyxtwq@treble>
Date:   Wed, 29 Jun 2022 09:34:00 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <llvm@...ts.linux.dev>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang
 support")

On Wed, Jun 29, 2022 at 09:08:20AM -0700, Linus Torvalds wrote:
> On Tue, Jun 28, 2022 at 3:43 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> >
> > So, something like this:
> 
> No, clang should just be fixed.
> 
> These UBSAN reports should usually be WARN_ON_ONCE.
> 
> It's all the same issues we've had before: causing a panic will just
> kill the machine, and gets us fewer reports.
> 
> Now, UBSAN is something that presumably normal people don't actually
> run on real hardware, so it's probably less of a deal than some. But
> hey, maybe somebody wants to actually run an UBSAN kernel on a real
> load with a full accelerated graphical UI and real drivers: a panic
> may end up killing the kernel, and there you sit, with a dead machine
> and no idea what went wrong.
> 
> So the whole "panic if UBSAN reports something" is COMPLETE GARBAGE.
> It actually makes the whole point of running UBSAN go away. You *lose*
> coverage.
> 
> So please don't make the kernel worse because clang got something like
> this wrong.
> 
> Just fix clang.
> 
> And fix your mindset.

Yeah, good point.  All the other UBSAN handlers (other than builtin
unreachable) try to recover.  There's nothing special about divrem
overflow which requires it to be fatal.

So clang needs to stop assuming the divrem overflow handler is noreturn.

-- 
Josh