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, 19 Feb 2020 14:43:39 -0800
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Chen Rong <rong.a.chen@...el.com>, Philip Li <philip.li@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        tip-bot2 for Josh Poimboeuf <tip-bot2@...utronix.de>,
        linux-tip-commits@...r.kernel.org, Borislav Petkov <bp@...e.de>,
        Julien Thierry <jthierry@...hat.com>, x86 <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [tip: core/objtool] objtool: Fail the kernel build on fatal errors

On Fri, Feb 14, 2020 at 9:58 AM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> On Fri, Feb 14, 2020 at 01:10:26AM +0100, Thomas Gleixner wrote:
> > Josh Poimboeuf <jpoimboe@...hat.com> writes:
> > > On Tue, Feb 11, 2020 at 12:47:38PM -0000, tip-bot2 for Josh Poimboeuf wrote:
> > >> The following commit has been merged into the core/objtool branch of tip:
> > >>
> > >> Commit-ID:     644592d328370af4b3e027b7b1ae9f81613782d8
> > >> Gitweb:        https://git.kernel.org/tip/644592d328370af4b3e027b7b1ae9f81613782d8
> > >> Author:        Josh Poimboeuf <jpoimboe@...hat.com>
> > >> AuthorDate:    Mon, 10 Feb 2020 12:32:38 -06:00
> > >> Committer:     Borislav Petkov <bp@...e.de>
> > >> CommitterDate: Tue, 11 Feb 2020 13:27:03 +01:00
> > >>
> > >> objtool: Fail the kernel build on fatal errors
> > >>
> > >> When objtool encounters a fatal error, it usually means the binary is
> > >> corrupt or otherwise broken in some way.  Up until now, such errors were
> > >> just treated as warnings which didn't fail the kernel build.
> > >>
> > >> However, objtool is now stable enough that if a fatal error is
> > >> discovered, it most likely means something is seriously wrong and it
> > >> should fail the kernel build.
> > >>
> > >> Note that this doesn't apply to "normal" objtool warnings; only fatal
> > >> ones.
> > >
> > > Clang still has some toolchain issues which need to be sorted out, so
> > > upgrading the fatal errors is causing their CI to fail.
> >
> > Good. Last time we made it fail they just fixed their stuff.
> >
> > > So I think we need to drop this one for now.
> >
> > Why? It's our decision to define which level of toolchain brokeness is
> > tolerable.
> >
> > > Boris, are you able to just drop it or should I send a revert?
> >
> > I really want to see a revert which has a proper justification why the
> > issues of clang are tolerable along with a clear statement when this
> > fatal error will come back. And 'when' means a date, not 'when clang is
> > fixed'.
>
> Fair enough.  The root cause was actually a bug in binutils which gets
> triggered by a new clang feature.  So instead of reverting the above
> patch, I think I've figured out a way to work around the binutils bug,
> while also improving objtool at the same time (win-win).
>
> The binutils bug will be fixed in binutils 2.35.
>
> BTW, to be fair, this was less "Clang has issues" and more "Josh is
> lazy".  I didn't test the patch with Clang -- I tend to rely on 0-day
> bot reports because I don't have the bandwidth to test the
> kernel/config/toolchain combinations.  Nick tells me Clang will soon be
> integrated with the 0-day bot, which should help prevent this type of
> thing in the future.

Hi Rong, Philip,
Do you have any status updates on turning on the 0day bot emails to
the patch authors in production?  It's been quite handy in helping us
find issues, for the private mails we've been triaging daily.
-- 
Thanks,
~Nick Desaulniers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ