linux-kernel - Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

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: <CAGXu5jLMCK6yudcp5kyGpC-CdHdhBFRGkzW84GfOjZPhyV2kOQ@mail.gmail.com>
Date:   Sat, 18 Nov 2017 00:20:56 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Patrick McLean <chutzpah@...too.org>,
        Emese Revfy <re.emese@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Bruce Fields <bfields@...hat.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11

On Fri, Nov 17, 2017 at 9:29 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Nov 17, 2017 at 9:14 PM, Kees Cook <keescook@...omium.org> wrote:
>>
>> FWIW, myself doing a build at d9e12200852d with and without
>> GCC_PLUGIN_RANDSTRUCT _appears_ to produce identical objdump output
>> where I did spot-checks.
>
> That would probably be a good thing to check anyway - check the
> difference between GCC_PLUGIN_RANDSTRUCT on and off at that commit.
>
> Just do
>
>    objdump --disassemble vmlinux > file
>
> and compare the two files for where the differences start occurring.

Yeah, I was just doing that now. Looks like there _is_ something
getting changed just from having the plugin enabled, but it appears
localized. For me, the first non-offset change happens in
lookup_user_key and persists for a while.

-ffffffff813893a7:      0f 85 55 03 00 00       jne
ffffffff81389702 <lookup_user_key+0x3f2>
-ffffffff813893ad:      f0 41 ff 06             lock incl (%r14)
-ffffffff813893b1:      83 fb 07                cmp    $0x7,%ebx
-ffffffff813893b4:      4c 89 b5 70 ff ff ff    mov    %r14,-0x90(%rbp)
...
+ffffffff813893a7:      0f 85 35 03 00 00       jne
ffffffff813896e2 <lookup_user_key+0x3d2>
+ffffffff813893ad:      4d 89 f0                mov    %r14,%r8
+ffffffff813893b0:      f0 41 ff 06             lock incl (%r14)
+ffffffff813893b4:      83 fb 07                cmp    $0x7,%ebx
+ffffffff813893b7:      4c 89 b5 70 ff ff ff    mov    %r14,-0x90(%rbp)

And removing the TYPE_ATTRIBUTES() poking makes the register storage
differences go away, but there's still a 0x40 byte offset delta.

I'll continue looking at this tomorrow.

-Kees

-- 
Kees Cook
Pixel Security