linux-kernel - [PATCH] ftrace/x86: Load ftrace_ops in parameter not the variable holding it

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

Message-ID: <20131108100646.07a63692@gandalf.local.home>
Date:	Fri, 8 Nov 2013 10:06:46 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: [PATCH] ftrace/x86: Load ftrace_ops in parameter not the variable
 holding it

Peter,

I found a bug in the ftrace callback code. When there's only one
function registered that supplies its own recursion protection, it gets
the ftrace_ops that it registered passed to it in the 3rd parameter
from assembly (otherwise, it gets it from a helper function).

But the assembly uses 'leaq' instead of 'movq' and instead of passing
the ftrace_ops to the callback, it passes in the address of the pointer
to the current ftrace_ops structure :-p.  Luckily, all users that needed
ftrace_ops so far used the helper function. But I have new code that
requires this to work that is scheduled for 3.14, I would like to get
this fix in for 3.13. As there are no current users of the direct
assembly passing, it's not required for stable.

I didn't know what branch to base this on in tip so I'm sending you the
patch here. You can pull in in directly or if you tell me which branch
to base on, I can send you a pull request. Your choice.

Thanks!

-- Steve

>From 95669fe1c8236af4519937d19545e65da0d29f1d Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>
Date: Thu, 7 Nov 2013 18:11:58 -0500
Subject: ftrace/x86: Load ftrace_ops in parameter not the variable
 holding it

Function tracing callbacks expect to have the ftrace_ops that registered it
passed to them, not the address of the variable that holds the ftrace_ops
that registered it.

Use a movq instead of a leaq to store the ftrace_ops into the parameter
of the function tracing callback.

Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
---
 arch/x86/kernel/entry_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index b077f4c..d7570c1 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -88,7 +88,7 @@ END(function_hook)
 	MCOUNT_SAVE_FRAME \skip

 	/* Load the ftrace_ops into the 3rd parameter */
-	leaq function_trace_op, %rdx
+	movq function_trace_op, %rdx

 	/* Load ip into the first parameter */
 	movq RIP(%rsp), %rdi
-- 
1.8.1.4

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