linux-kernel - Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

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]

Date:	Tue, 24 Nov 2009 12:30:39 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Haley <aph@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Jakub Jelinek <jakub@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	feng.tang@...el.com, Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	David Daney <ddaney@...iumnetworks.com>,
	Richard Guenther <richard.guenther@...il.com>,
	gcc <gcc@....gnu.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect
 GCC messing with mcount prologue

On Tue, 2009-11-24 at 17:12 +0000, Andrew Haley wrote:
> H. Peter Anvin wrote:

> > If we're changing gcc anyway, then let's add the option of intercepting
> > the function at the point where the machine state is well-defined by
> > ABI, which is before the function stack frame is set up.
> 
> Hmm.  On the x86 I suppose we could just inject a naked call instruction,
> but not all aeches allow us to call anything before we've saved the return
> address.  Or are you talking x86 only?

Earlier in the GCC BUG thread we talked about this. Adding a __fentry__
call at the beginning of the function. This could be done for other
archs as well, but yes, the return address must be stored. For x86 it is
the easiest because it automatically stores the return address on the
stack (Andi already has a working patch I believe).

For other archs, Linus showed some examples:

http://lkml.org/lkml/2009/11/19/349

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/