linux-kernel - Re: objtool warning: "duplicate frame pointer save"

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: <20160525175631.44xgcylo24ysftss@treble>
Date:	Wed, 25 May 2016 12:56:31 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	DRI <dri-devel@...ts.freedesktop.org>
Subject: Re: objtool warning: "duplicate frame pointer save"

On Wed, May 25, 2016 at 10:14:24AM -0700, Linus Torvalds wrote:
> Josh,
>  my current git version (with gcc 5.3.1) makes objtool warn about
> "duplicate frame pointer save" in drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> for both vmw_send_msg() and vmw_host_get_guestinfo().
> 
> The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
> (a "rep outsb") to communicate with the hypervisor (it's a virtual GPU
> driver for vmware), and %rbp is part of the communication. So the
> inline asm does a save-and-restore of the frame pointer around the
> instruction sequence.
> 
> I actually find the objtool warning to be quite reasonable, so it's
> not exactly a false positive, since in this case it actually does
> point out that the frame pointer won't be reliable over that
> instruction sequence.
> 
> But in this particular case it just ends up being the wrong thing -
> the code is what it is, and %rbp just can't have the frame information
> due to annoying magic calling conventions.
> 
> Is there some way to override objtool for this situation? I hate
> seeing warnings that I need to ignore, it has just too often caused me
> to mistakenly ignore warnings I *should* have reacted to.
> 
> I guess a STACK_FRAME_NON_STANDARD will shut objtool up (or just
> disabling it entirely for the whole file), but I was wondering about
> something more targeted that could be marked in the inline asm itself
> (rather than have to mark the functions that use it)

I used to have a STACKTOOL_IGNORE_INSN macro that would tell the tool to
skip warnings for specific instructions in inline asm:

Here's an example of it how it was used:

  https://lkml.kernel.org/r/c0c1a92df921961cae5cce208247bb8d8a975d6d.1450442274.git.jpoimboe@redhat.com

And here's the implementation of the macro:

  https://lkml.kernel.org/r/cd7778181d2a5251c3dc21811fdbcaa2c16c98c3.1450442274.git.jpoimboe@redhat.com

As it turns out, we didn't need the macro, so I removed it.  But I can
easily add something like that again to get rid of the warnings.

There were objections to having "OBJTOOL" in the names of macros, so I
guess I'll call it STACK_INSN_NON_STANDARD, unless anybody has a better
idea.

-- 
Josh