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

Message-ID: <20190718232015.bazk37cqbweh52pc@treble>
Date:   Thu, 18 Jul 2019 18:20:15 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Nick Desaulniers <ndesaulniers@...gle.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 Thu, Jul 18, 2019 at 03:36:47PM -0700, Nick Desaulniers wrote:
> 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?

That looks ok.  I'm not sure whether removing the stack alignment would
fix it though, you might have just gotten lucky.

> 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?)

Yeah, I think calling a variadic function (or a function with more than
6 args) does have something to do with it, because then some arguments
have to be passed on the stack.

-- 
Josh