On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> 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@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:
>
>> 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?
>>>
>>> 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.
>
> 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...
-Kees
--
Kees Cook
Pixel Security