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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jJwDDKKzWYszuAMP=2KL_LX=Ngvdk=_3rENJD_GJ-QmNQ@mail.gmail.com>
Date:   Thu, 15 Feb 2018 19:41:35 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: objtool warnings on 4.14-stable/gcc-7.3.0

On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook <keescook@...omium.org> wrote:
> On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@...hat.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@...hat.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?

-Kees

-- 
Kees Cook
Pixel Security