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  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]
Date:	Tue, 18 Nov 2014 22:33:31 -0500
From:	Steven Rostedt <>
Cc:	Ingo Molnar <>,
	Andrew Morton <>,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>,,
	Masami Hiramatsu <>,
	Namhyung Kim <>
Subject: [PATCH 0/2] ftrace: Fix stack tracing issues

I ran my ftrace tests on a PREEMPT_RT kernel and one of the tests failed.
It triggered a race that was in mainline and was fixed by another patch.
The bug was with the traceoff function trigger.

I stated testing the other triggers and discovered two other bugs.
One was caused by my latest changes, but the other one has been in
mainline for some time. It's been there since 3.16, and I haven't
tested it further. It's not that big of a bug so I'm not labeling
it with stable.

The bug that's been there happens when CONFIG_FRAME_POINTERS is set.
The ftrace trampoline doesn't set up a frame pointer, and the stack
trace code will miss the called function. That is if you do:

 echo __kmalloc:stacktrace > set_ftrace_filter

It will not show __kmalloc in the trace. This isn't that bad, but if
fentry is used (compiled with gcc 4.6 and newer on x86), then not only
is __kmalloc missed, but also the function that called __kmalloc.
This is a bit more serious, as that is useful information. The reason
for the difference with fentry, is that the fentry is called before
the stack frame is set up, so the missing bp frame pointer goes back
pass the parent.

The second bug is with the new code and dynamic ftrace trampolines.
There's a check in the stack trace recording to see if the address
on the stack is kernel code or not. This checks core kernel text as
well as module address. But it doesn't check if it is a dynamically
allocated ftrace trampoline. This is much worse than the other bug
because if FRAME_POINTERS is set, the pointer to the trampoline is
skipped and the bp frame pointer is never updated. That means, no
functions will be traced. Makes the stack trace from function tracing
rather pointless. Luckily, that code is not in mainline yet and this
fix will make sure mainline doesn't get the bug (except for bisects).


-- Steve

Steven Rostedt (Red Hat) (2):
      ftrace/x86: Add frames pointers to trampoline as necessary
      ftrace/x86/extable: Add is_ftrace_trampoline() function

 arch/x86/kernel/ftrace.c    |  9 +++++++--
 arch/x86/kernel/mcount_64.S | 41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/ftrace.h      |  8 ++++++++
 kernel/extable.c            |  3 +++
 kernel/trace/ftrace.c       | 26 ++++++++++++++++++++++++++
 5 files changed, 85 insertions(+), 2 deletions(-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists