mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Jiri Kosina <jkosina@suse.cz>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Petr Mladek <pmladek@suse.com>
Subject: [PATCH 1/4] ftrace/x86: Make sure to modify 5-bite instructions
Date: Mon, 27 Jun 2016 15:54:34 +0200	[thread overview]
Message-ID: <1467035677-12193-2-git-send-email-pmladek@suse.com> (raw)
In-Reply-To: <1467035677-12193-1-git-send-email-pmladek@suse.com>

The commit 8329e818f14926a604 ("ftrace/x86: Set ftrace_stub to weak to
prevent gcc from using short jumps to it") fixed a situation where we
replaced 2-byte with 5-byte jump instruction.

The original problem crashed the kernel with

  # cd /sys/kernel/trace
  # echo function_graph > current_tracer
  # echo nop > current_tracer

  [   78.122055] invalid opcode: 0000 [#1] SMP
  [   78.125125] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass \
crc32c_intel pcspkr iwldvm iwlwifi  [   78.128241] CPU: 2 PID: 17 Comm: migration/2 \
Not tainted 4.6.0-rc4+ #36  [   78.131310] Hardware name: LENOVO 4286A74/4286A74, \
BIOS 8DET56WW (1.26 ) 12/01/2011  [   78.134369] task: ffff88040bec4240 ti: \
ffff88040bee4000 task.ti: ffff88040bee4000  [   78.137412] RIP: \
0010:[<ffffffff818939a8>]  [<ffffffff818939a8>] ftrace_stub+0x0/0x8  [   78.140477] \
RSP: 0018:ffff88040bee7e48  EFLAGS: 00010246  [   78.143489] RAX: ffff88040bec4240 \
RBX: ffffffff8107a7b0 RCX: 000000000000001f  [   78.146512] RDX: 0000000000000000 \
RSI: ffff88041e2929d8 RDI: ffff88040bee7e50  [   78.149581] RBP: ffff88040bee7e80 \
R08: ffff88040bee4000 R09: 0000000000000000  [   78.152647] R10: 00000000000318b7 \
R11: ffff8800d661f800 R12: ffff88040d8011b0  [   78.155679] R13: ffffffff81e43620 \
R14: ffff88040bda8588 R15: ffffffff81e503e0  [   78.158675] FS:  \
0000000000000000(0000) GS:ffff88041e280000(0000) knlGS:0000000000000000  [   \
78.161699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  [   78.164690] CR2: \
00007fadb22dde1d CR3: 00000000d5ce2000 CR4: 00000000000406e0  [   78.167691] Stack:
  [   78.170658]  ffffffff8110b3ee ffffffff8188de90 00000009161d55f6 00000012306fc2e4
  [   78.173710]  0000000000000000 ffff880400000000 ffff88040bec4240 ffff88040bee7ec8
  [   78.176783]  ffffffff81893bbd 0000000000000000 ffff88040bec4240 ffffffff81893ba8
  [   78.179863] Call Trace:
  [   78.182853]  [<ffffffff8110b3ee>] ? ftrace_return_to_handler+0x8e/0x100
  [   78.185909]  [<ffffffff8188de90>] ? __schedule+0xae0/0xae0
  [   78.188941]  [<ffffffff81893bbd>] return_to_handler+0x15/0x27
  [   78.192001]  [<ffffffff81893ba8>] ? ftrace_graph_caller+0xa8/0xa8
  [   78.195091]  [<ffffffff8107a6f0>] ? sort_range+0x30/0x30
  [   78.198138]  [<ffffffff810778a9>] kthread+0xc9/0xe0
  [   78.201143]  [<ffffffff81891a12>] ret_from_fork+0x22/0x40
  [   78.204138]  [<ffffffff810777e0>] ? kthread_worker_fn+0x170/0x170
  [   78.207129] Code: 8b 44 24 48 48 8b 7c 24 70 48 8b 74 24 68 48 8b 54 24 60
                       48 8b 4c 24 58 48 8b 44 24 50 48 8b 6c 24 20 48 81 c4 d0
                       00 00 00 e9 fd <ff> ff ff 80 00 00 00 00 9c 55 ff 74 24 18
                       55 48 89 e5 ff 74 24
  [   78.213997] RIP  [<ffffffff818939a8>] ftrace_stub+0x0/0x8
  [   78.217190]  RSP <ffff88040bee7e48>
  [   78.220374] ---[ end trace 0af2f0d9f7301011 ]---

, see
https://lkml.kernel.org/g/1463147623-2575-1-git-send-email-namhyung@kernel.org

We already avoid similar crashes by paranoid checks, for example
in add_break() or ftrace_modify_code_direct(). These checks did
not help in the above situation because the old expected code
was read from the location that was modified. See the memcpy()
in update_ftrace_func().

Normally, the expected code is generated according to the expected
state of the modified location. update_ftrace_func() is called
in several situations. It is not easy to generate the expected code
a reasonable way. But the function seems to be called only when
we modify a call or a jump instruction. We could at least check
that it is the 5-byte variant.

Signed-off-by: Petr Mladek <pmladek@suse.com>
---
 arch/x86/kernel/ftrace.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index d036cfb4495d..42ea69d35dfd 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -235,6 +235,15 @@ static int update_ftrace_func(unsigned long ip, void *new)
 
 	memcpy(old, (void *)ip, MCOUNT_INSN_SIZE);
 
+	/*
+	 * Make sure that we replace 5-byte instruction that
+	 * is either a call or a jump.
+	 */
+	if (old[0] != 0xe8 && old[0] != 0xe9) {
+		pr_warn("Expected e8 or e9, got %x\n", old[0]);
+		return -EINVAL;
+	}
+
 	ftrace_update_func = ip;
 	/* Make sure the breakpoints see the ftrace_update_func update */
 	smp_wmb();
-- 
1.8.5.6

  reply	other threads:[~2016-06-27 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27 13:54 [PATCH 0/4] ftrace: One more check on x86 and some small fixes Petr Mladek
2016-06-27 13:54 ` Petr Mladek [this message]
2016-06-27 13:54 ` [PATCH 2/4] ftrace/x86: Do not crash when reading wrong ftrace func Petr Mladek
2016-06-27 14:48   ` Steven Rostedt
2016-06-28 10:00     ` Petr Mladek
2016-06-27 13:54 ` [PATCH 3/4] ftrace: Always destroy trampoline when shutting down the trace Petr Mladek
2016-06-27 13:54 ` [PATCH 4/4] ftrace: Fixup trace_selftest_ops() Petr Mladek
2016-06-28  5:22 ` [PATCH 0/4] ftrace: One more check on x86 and some small fixes Namhyung Kim
2016-06-28 19:17 ` Steven Rostedt
2016-06-29  8:22   ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1467035677-12193-2-git-send-email-pmladek@suse.com \
    --to=pmladek@suse.com \
    --cc=fweisbec@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®