On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook keescook@chromium.org wrote:
On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf jpoimboe@redhat.com wrote:
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:
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.
Uuhhh... I don't see the NULL deref, and even if it was eliminating later stuff, I'd still expect a pr_info() ...
void lkdtm_CORRUPT_LIST_ADD(void) { /* * Initially, an empty list via LIST_HEAD: * test_head.next = &test_head * test_head.prev = &test_head */ LIST_HEAD(test_head); struct lkdtm_list good, bad; void *target[2] = { }; void *redirection = ⌖
pr_info("attempting good list addition\n");...
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.
This seems like a very rare combination, the flags I need to reproduce are "gcc -O2 -mno-red-zone -mpreferred-stack-boundary=3 -march=nocona", however I do see the same behavior with every gcc version since 4.8!
Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl show this, but none of the modern microarchitectures do.
I'll see if I can reproduce this...
To clarify, this is _only_ on 4.14, gcc 7.3.0, and any of march=nocona, bonnell, atom, silvermont, slm, or knl ?
Is it present in latest Linus and/or with gcc 8?
-Kees