linux-kernel - Re: objtool warnings on 4.14-stable/gcc-7.3.0

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: <20180215152521.eoz6mhgw22ekyaev@treble>
Date:   Thu, 15 Feb 2018 09:25:21 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: objtool warnings on 4.14-stable/gcc-7.3.0

On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> >> > Hi Josh,
> >> >
> >> > I recently did some randconfig testing with a plain 4.14-stable kernel
> >> > and gcc-7.3.0, and came across three distinct objtool warnings:
> >> >
> >> > drivers/misc/lkdtm_bugs.o: warning: objtool:
> >> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> >
> > While this is probably an objtool bug, the code is very odd:
> >
> > 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
> >  1a8:   e8 00 00 00 00          callq  1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
> >                         1a9: R_X86_64_PC32      __fentry__-0x4
> >  1ad:   55                      push   %rbp
> >  1ae:   48 89 e5                mov    %rsp,%rbp
> >  1b1:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
> >  1b5:   48 83 ec 20             sub    $0x20,%rsp
> >  1b9:   48 89 ec                mov    %rbp,%rsp
> >  1bc:   5d                      pop    %rbp
> >  1bd:   c3                      retq
> >
> > The function just allocates/aligns its stack space and then returns.  It
> > seems like GCC was too smart for its own good here, as the function
> > doesn't test what it's supposed to.
> 
> AFAIU, there is an optimization step in gcc that eliminates basic blocks
> that contain an unconditional NULL pointer dereference, based on the
> assumption that it's undefined behavior, and if we ever get here, it is
> free to drop not only code after but also before it as long as it doesn't
> have any side-effects.

Ok, I expected something like that.  GCC "undefined behavior" strikes
again.

Kees, I suppose you'll need to obfuscate the code to stay one step ahead
of GCC.

While this may be an objtool bug, I might not fix it because it served a
useful purpose here in finding GCC crap.

> I would have expected an actual NULL pointer dereference to remain
> in the function though, or at least another trapping instruction.
> 
> >  Can you share the config for this one?
> 
> https://pastebin.com/qFV6SPWP

Would be interesting to analyze that config to understand what options
are causing GCC to do that.  I don't see this "optimization" with my
config.

-- 
Josh