linux-kernel - Re: objtool crashes on clang output (drivers/hwmon/pmbus/adm1275.o)

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: <CAKwvOdm_MiACJWnRww3tSD7033J6MX2Erzs1xwmd1=taNmyg9A@mail.gmail.com>
Date:   Thu, 18 Jul 2019 15:36:47 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: objtool crashes on clang output (drivers/hwmon/pmbus/adm1275.o)

On Tue, Jul 16, 2019 at 4:03 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> On Wed, Jul 17, 2019 at 12:05:14AM +0200, Arnd Bergmann wrote:
> > On Tue, Jul 16, 2019 at 10:24 PM 'Nick Desaulniers' via Clang Built
> > Linux <clang-built-linux@...glegroups.com> wrote:
> > >
> > > On Fri, Jul 12, 2019 at 1:41 PM Arnd Bergmann <arnd@...db.de> wrote:
> > > >
> > > > On Fri, Jul 12, 2019 at 6:59 PM 'Nick Desaulniers' via Clang Built
> > > > Linux <clang-built-linux@...glegroups.com> wrote:
> > > > > > The issue still needs to get fixed in clang regardless.  There are other
> > > > > > noreturn functions in the kernel and this problem could easily pop back
> > > > > > up.
> > > > >
> > > > > Sure, thanks for the report.  Arnd, can you help us get a more minimal
> > > > > test case to understand the issue better?
> > > >
> > > > I reduced it to this testcase:
> > > >
> > > > int a, b;
> > > > void __reiserfs_panic(int, ...) __attribute__((noreturn));
> > > > void balance_internal() {
> > > >   if (a)
> > > >     __reiserfs_panic(0, "", __func__, "", 2, __func__, a);
> > > >   if (b)
> > > >     __reiserfs_panic(0, "", __func__, "", 5, __func__, a, 0);
> > > > }
> > > >
> > > > https://godbolt.org/z/Byfvmx
> > >
> > > Is this the same issue as Josh pointed out?  IIUC, Josh pointed to a
> > > jump destination that was past a `push %rbp`, and I don't see it in
> > > your link.  (Or, did I miss it?)
> >
> > I think it can be any push. The point is that the stack is different
> > between the two branches leading up to the noreturn call.
>
> Right.

So if I remove the `-mstack-alignment=8` command line flag, it looks
like the stack depth will still differ on calls to __reiserfs_panic,
but now the call is not shared (two separate code paths):
https://godbolt.org/z/tvkXwK. Is that ok or also bad?

I'm getting the feeling that `-mstack-alignment=8` might have some
issues once we start pushing parameters on the stack.  How many can we
use registers for in x86 before resorting to the stack, and does the
function being variadic affect this? (if not, maybe a test case
without variadic and many-parameters would not conflate the issue?)
-- 
Thanks,
~Nick Desaulniers