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

Message-ID: <4B0D9AF3.6000702@redhat.com>
Date:	Wed, 25 Nov 2009 21:00:35 +0000
From:	Andrew Haley <aph@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Jakub Jelinek <jakub@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H.J. Lu" <hjl.tools@...il.com>, rostedt@...dmis.org,
	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>
Subject: Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC
 messing with mcount prologue

H. Peter Anvin wrote:
> On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>> If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
>> then certainly coming up with a new gcc switch and new profiling ABI is
>> desirable.  -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
>> makes code on these register starved arches significantly worse.
>> Making GCC output profiling call before prologue instead of after prologue
>> is a 4 liner in generic code and a few lines in target specific code.
>> The important thing is that we shouldn't have 100 different profiling ABIs,
>> so it is desirable to agree on something that will be generally useful not
>> just for the kernel, but perhaps for other purposes.
> 
> There is really just one that makes sense, which is providing the
> ABI-defined entry state, which means intercepting at the point of entry.
> 
> Anything else is/was a mistake.

Indeed.  The problem, though, is that the "naked call" approach, while attractive,
requires the back end to be modified and so requires the help of the gcc maintainers
for every Linux target.  Not that this is a terrible idea, but such co-ordination
is going to take time.

Andrew.
--
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/