linux-kernel - profile_pc() bogus since <= 2.6.19 (x86 at least)?

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

Message-Id: <47CE8EAD.76E4.0078.0@novell.com>
Date:	Wed, 05 Mar 2008 11:14:37 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	<linux-kernel@...r.kernel.org>
Subject: profile_pc() bogus since <= 2.6.19 (x86 at least)?

Ingo,

while the comment at the top of kernel/spinlock.c states so:

 * Note that some architectures have special knowledge about the
 * stack frames of these functions in their profile_pc. If you
 * change anything significant here that could change the stack
 * frame contact the architecture maintainers.

the actual code doesn't seem to match this anymore. With all (and
even before that, many) functions being written in C, there cannot
be validly made assumptions about the stack frame layout. Indeed,
if I check the disassembly framed by __lock_text_{start,end} on
x86, there are a number of functions that push one or two registers
(in lock_kernel() even stack variables are being allocated), which
clearly breaks profile_pc()'s assumptions.

Since it's been this way for so long, I wonder how frequently this
code is actually being exercised...

Jan

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