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@redhat.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?
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.