linux-kernel - Re: [PATCH 00/22] x86, objtool: several fixes/improvements

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] [day] [month] [year] [list]

Date:   Fri, 27 Sep 2019 13:24:50 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH 00/22] x86, objtool: several fixes/improvements

On Thu, Jul 18, 2019 at 3:26 PM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> On Tue, Jul 16, 2019 at 4:17 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> >
> > > > > 2) There's also an issue in clang where a large switch table had a bunch
> > > > >    of unused (bad) entries.  It's not a code correctness issue, but
> > > > >    hopefully it can get fixed in clang anyway.  See patch 20/22 for more
> > > > >    details.
> > >
> > > Thanks for the report, let's follow up on steps for me to reproduce.
> >
> > Just to clarify, there are two clang issues.  Both of them were reported
> > originally by Arnd, IIRC.
> >
> > 1) The one described above and in patch 20, where the switch table is
> >    mostly unused entries.  Not a real bug, but it's a bit sloppy and
> >    wasteful, and objtool doesn't know how to interpret it.
>
> Thanks for the concise reports.  Will follow up on these in:
> https://github.com/ClangBuiltLinux/linux/issues/611

Following up on this one; in one of the test cases we determined that
the default destination of an exhaustive switch wasn't getting cleaned
up properly, and is being fixed in:
https://reviews.llvm.org/D68131
https://bugs.llvm.org/show_bug.cgi?id=43129
I'm not sure that was the precise issue you described, or if there's
more than one bug here, but hopefully it will help.

>
> >
> > 2) The bug with the noreturn call site having a different stack size
> >    depending on which code path was taken.
>
> and:
> https://github.com/ClangBuiltLinux/linux/issues/612
-- 
Thanks,
~Nick Desaulniers