linux-kernel - [PATCH 0/2] [GIT PULL][for 2.6.31] function graph gcc issue

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: <20090618224409.916725341@goodmis.org>
Date:	Thu, 18 Jun 2009 18:44:09 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: [PATCH 0/2] [GIT PULL][for 2.6.31] function graph gcc issue

Ingo,

The bug I spent two days debugging that Jake found was due to gcc
making a copy of the return address into the stack frame and not
using it to actually return. The function graph tracer would modify
the copy and not the actual location that was used to return to.
Thus the accounting of the function graph tracer was corrupted and
a nasty crash followed.

I found that 32bit x86 when compiled with optimize for size caused
this issue in the latest gcc (4.4.0). The first patch makes the
function graph tracer depend on !X86_32 || !CC_OPTIMIZE_FOR_SIZE.
This way we keep from getting into trouble with a know configuration
that breaks.

Then next patch adds to x86 (both 32bit and 64bit) a test of the
frame pointer to make sure that the return actually goes to where
we expect it to.

When debugging Jakes bug, The first instance was easy to find. It was
the timer_stats_update_stats that had a forced cacheline struct as a local.
I changed that and it seemed to fix the boot up test. When I enabled
function graph at run time, the system crashed again, but this time the
crash was hard to find where the issue was. I wrote up this test (patch 2)
and I found the problem immediately. In case gcc changes, we want to be
able to detect it right away before the tracer does anything dangerous.

Please pull the latest tip/tracing/urgent-1 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/urgent-1

Steven Rostedt (2):
      function-graph: disable when both x86_32 and optimize for size are configured
      function-graph: add stack frame test

----
 arch/powerpc/kernel/ftrace.c         |    2 +-
 arch/s390/kernel/ftrace.c            |    2 +-
 arch/x86/Kconfig                     |    1 +
 arch/x86/kernel/entry_32.S           |    2 +
 arch/x86/kernel/entry_64.S           |    2 +
 arch/x86/kernel/ftrace.c             |    6 +++-
 include/linux/ftrace.h               |    4 ++-
 kernel/trace/Kconfig                 |    8 +++++++
 kernel/trace/trace_functions_graph.c |   36 ++++++++++++++++++++++++++++++---
 9 files changed, 54 insertions(+), 9 deletions(-)
-- 
--
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/