linux-kernel - Re: two more objtool warnings: lib/ubsan.o and fs/fs

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] [day] [month] [year] [list]

Date:   Thu, 10 Aug 2017 16:39:12 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: two more objtool warnings: lib/ubsan.o and fs/fs_pin.o

On Fri, Jul 28, 2017 at 12:04:47PM -0500, Josh Poimboeuf wrote:
> On Fri, Jul 28, 2017 at 01:25:27PM +0200, Arnd Bergmann wrote:
> > Hi Josh,
> > 
> > I ran into two more warnings with the two patches you sent me in private,
> > using gcc-7.1.1:
> > 
> > lib/ubsan.o: warning: objtool: val_to_string.constprop.7()+0x97: leave
> > instruction with modified stack frame
> > .config: https://pastebin.com/dl/g04Dwdwx
> > 
> > fs/fs_pin.o: warning: objtool: pin_kill()+0x139: stack state mismatch:
> > cfa1=7+88 cfa2=7+96
> > .config: https://pastebin.com/dl/6gK6MadB
> > 
> > I assume you are faster at analysing than me, so I have not tried to get
> > to the bottom of these at all. Let me know if you need help reproducing
> > the warnings. It's also possible that they are fixed by some other patches
> > that you already sent but that are not in linux-next yet.
> 
> Thanks.  The first one is a relatively easy fix in objtool's drap
> register handling.  I have a working patch for it.
> 
> The second one is a little trickier.
> 
> Instead of:
> 
>   lea	0x8(%rsp), %rsp
> 
> GCC is doing:
> 
>   lea    0x8(%rsp), %rcx
>   mov    %rcx, %rsp
> 
> I don't see why GCC would do that.  We should probably ask some GCC
> folks.  Objtool isn't built to track register values, so it may be a
> little tricky to deal with that pattern correctly if we can't convince
> GCC to fix it.
> 
> Anyway, I'm going to be on vacation next week, but I'll investigate
> further when I get back.

I posted a patch for the first issue and I'll open a GCC bug for the
second issue.

-- 
Josh