linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tip-bot for Peter Zijlstra <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: dvyukov@google.com, jpoimboe@redhat.com,
	torvalds@linux-foundation.org, mingo@kernel.org,
	eranian@google.com, alexander.shishkin@linux.intel.com,
	acme@kernel.org, jolsa@redhat.com, linux-kernel@vger.kernel.org,
	acme@redhat.com, tglx@linutronix.de, davej@codemonkey.org.uk,
	vincent.weaver@maine.edu, eranian@gmail.com,
	peterz@infradead.org, hpa@zytor.com
Subject: [tip:perf/urgent] perf/x86/intel: Cure bogus unwind from PEBS entries
Date: Tue, 22 Nov 2016 04:30:24 -0800	[thread overview]
Message-ID: <tip-b8000586c90b4804902058a38d3a59ce5708e695@git.kernel.org> (raw)
In-Reply-To: <20161117171731.GV3157@twins.programming.kicks-ass.net>

Commit-ID:  b8000586c90b4804902058a38d3a59ce5708e695
Gitweb:     http://git.kernel.org/tip/b8000586c90b4804902058a38d3a59ce5708e695
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Thu, 17 Nov 2016 18:17:31 +0100
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 22 Nov 2016 12:36:58 +0100

perf/x86/intel: Cure bogus unwind from PEBS entries

Vince Weaver reported that perf_fuzzer + KASAN detects that PEBS event
unwinds sometimes do 'weird' things. In particular, we seemed to be
ending up unwinding from random places on the NMI stack.

While it was somewhat expected that the event record BP,SP would not
match the interrupt BP,SP in that the interrupt is strictly later than
the record event, it was overlooked that it could be on an already
overwritten stack.

Therefore, don't copy the recorded BP,SP over the interrupted BP,SP
when we need stack unwinds.

Note that its still possible the unwind doesn't full match the actual
event, as its entirely possible to have done an (I)RET between record
and interrupt, but on average it should still point in the general
direction of where the event came from. Also, it's the best we can do,
considering.

The particular scenario that triggered the bogus NMI stack unwind was
a PEBS event with very short period, upon enabling the event at the
tail of the PMI handler (FREEZE_ON_PMI is not used), it instantly
triggers a record (while still on the NMI stack) which in turn
triggers the next PMI. This then causes back-to-back NMIs and we'll
try and unwind the stack-frame from the last NMI, which obviously is
now overwritten by our own.

Analyzed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davej@codemonkey.org.uk <davej@codemonkey.org.uk>
Cc: dvyukov@google.com <dvyukov@google.com>
Cc: stable@vger.kernel.org
Fixes: ca037701a025 ("perf, x86: Add PEBS infrastructure")
Link: http://lkml.kernel.org/r/20161117171731.GV3157@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/events/intel/ds.c   | 35 +++++++++++++++++++++++------------
 arch/x86/events/perf_event.h |  2 +-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 0319311..be20239 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1108,20 +1108,20 @@ static void setup_pebs_sample_data(struct perf_event *event,
 	}
 
 	/*
-	 * We use the interrupt regs as a base because the PEBS record
-	 * does not contain a full regs set, specifically it seems to
-	 * lack segment descriptors, which get used by things like
-	 * user_mode().
+	 * We use the interrupt regs as a base because the PEBS record does not
+	 * contain a full regs set, specifically it seems to lack segment
+	 * descriptors, which get used by things like user_mode().
 	 *
-	 * In the simple case fix up only the IP and BP,SP regs, for
-	 * PERF_SAMPLE_IP and PERF_SAMPLE_CALLCHAIN to function properly.
-	 * A possible PERF_SAMPLE_REGS will have to transfer all regs.
+	 * In the simple case fix up only the IP for PERF_SAMPLE_IP.
+	 *
+	 * We must however always use BP,SP from iregs for the unwinder to stay
+	 * sane; the record BP,SP can point into thin air when the record is
+	 * from a previous PMI context or an (I)RET happend between the record
+	 * and PMI.
 	 */
 	*regs = *iregs;
 	regs->flags = pebs->flags;
 	set_linear_ip(regs, pebs->ip);
-	regs->bp = pebs->bp;
-	regs->sp = pebs->sp;
 
 	if (sample_type & PERF_SAMPLE_REGS_INTR) {
 		regs->ax = pebs->ax;
@@ -1130,10 +1130,21 @@ static void setup_pebs_sample_data(struct perf_event *event,
 		regs->dx = pebs->dx;
 		regs->si = pebs->si;
 		regs->di = pebs->di;
-		regs->bp = pebs->bp;
-		regs->sp = pebs->sp;
 
-		regs->flags = pebs->flags;
+		/*
+		 * Per the above; only set BP,SP if we don't need callchains.
+		 *
+		 * XXX: does this make sense?
+		 */
+		if (!(sample_type & PERF_SAMPLE_CALLCHAIN)) {
+			regs->bp = pebs->bp;
+			regs->sp = pebs->sp;
+		}
+
+		/*
+		 * Preserve PERF_EFLAGS_VM from set_linear_ip().
+		 */
+		regs->flags = pebs->flags | (regs->flags & PERF_EFLAGS_VM);
 #ifndef CONFIG_X86_32
 		regs->r8 = pebs->r8;
 		regs->r9 = pebs->r9;
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 5874d8d..a77ee02 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -113,7 +113,7 @@ struct debug_store {
  * Per register state.
  */
 struct er_account {
-	raw_spinlock_t		lock;	/* per-core: protect structure */
+	raw_spinlock_t      lock;	/* per-core: protect structure */
 	u64                 config;	/* extra MSR config */
 	u64                 reg;	/* extra MSR number */
 	atomic_t            ref;	/* reference count */

  reply	other threads:[~2016-11-22 12:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 17:43 perf: fuzzer KASAN unwind_get_return_address Vince Weaver
2016-11-15 18:57 ` Peter Zijlstra
2016-11-15 19:04   ` Dmitry Vyukov
2016-11-15 20:56     ` Josh Poimboeuf
2016-11-15 19:05   ` Vince Weaver
2016-11-15 20:57     ` Josh Poimboeuf
2016-11-16 13:03       ` Peter Zijlstra
2016-11-16 13:18         ` Dmitry Vyukov
2016-11-16 14:37         ` Josh Poimboeuf
2016-11-16 14:49           ` Peter Zijlstra
2016-11-16 14:58             ` Josh Poimboeuf
2016-11-16 14:58             ` Peter Zijlstra
2016-11-17  4:48               ` Josh Poimboeuf
2016-11-17  9:04                 ` Peter Zijlstra
2016-11-17  9:13                   ` Peter Zijlstra
2016-11-17  9:30                     ` Peter Zijlstra
2016-11-17  9:48                       ` Dmitry Vyukov
2016-11-17 14:01                         ` Josh Poimboeuf
2016-11-17 14:25                           ` Vince Weaver
2016-11-17 14:36                             ` Josh Poimboeuf
2016-11-17 14:58                               ` Dmitry Vyukov
2016-11-17 17:15                                 ` Vince Weaver
2016-11-17 15:18                   ` Josh Poimboeuf
2016-11-17 16:07                     ` Peter Zijlstra
2016-11-17 17:17                       ` Peter Zijlstra
2016-11-22 12:30                         ` tip-bot for Peter Zijlstra [this message]
2016-11-16 15:06             ` Vince Weaver
2016-11-17 15:57         ` [PATCH 1/2] unwind: prevent KASAN false positive warnings in guess unwinder Josh Poimboeuf
2016-11-17 15:57           ` [PATCH 2/2] dumpstack: prevent KASAN false positive warnings Josh Poimboeuf
2016-11-18  9:04             ` [tip:x86/urgent] x86/dumpstack: Prevent " tip-bot for Josh Poimboeuf
2016-11-17 20:26           ` [PATCH 1/2] unwind: prevent KASAN false positive warnings in guess unwinder Josh Poimboeuf
2016-11-18  8:38             ` Ingo Molnar
2016-11-18  9:04           ` [tip:x86/urgent] x86/unwind: Prevent " tip-bot for Josh Poimboeuf

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=tip-b8000586c90b4804902058a38d3a59ce5708e695@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=davej@codemonkey.org.uk \
    --cc=dvyukov@google.com \
    --cc=eranian@gmail.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.weaver@maine.edu \
    /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;
as well as URLs for NNTP newsgroup(s).