lkml.org 
[lkml]   [2018]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: objtool warnings on 4.14-stable/gcc-7.3.0
On Fri, Feb 16, 2018 at 4:41 AM, Kees Cook <keescook@chromium.org> wrote:
> 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 = &target;
>>
>> 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...
>
> 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?

It is with all modern gcc versions: 4.8 though 8.0.1 on those -march
values, and it still appears on latest Linus and next/master.

Arnd

\
 
 \ /
  Last update: 2018-02-16 16:11    [W:0.049 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site