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

[Josh Poimboeuf]

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@xxxxxxxxxx> 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