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: <CAK8P3a1Q8O7=Wt71RkB0hqZA1dPGZMaBxVwyrx0+d2pPsDb8gQ@mail.gmail.com>
Date:   Thu, 15 Feb 2018 16:01:57 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     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 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:
>> > 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.

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?

https://pastebin.com/qFV6SPWP

        Arnd