linux-kernel - [PATCH 2/2] perf/x86/intel: Fix PMI handling for Intel PT

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

Date:	Thu, 11 Jun 2015 15:13:57 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>
Cc:	linux-kernel@...r.kernel.org, adrian.hunter@...el.com,
	x86@...nel.org, hpa@...or.com, acme@...radead.org,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: [PATCH 2/2] perf/x86/intel: Fix PMI handling for Intel PT

Since Intel PT is a separate pmu and is not using any of the x86_pmu
code paths, which means in particular that active_events counter remains
intact when new PT events are created. However, PT uses x86_pmu PMI
handler for its PMI handling needs. The problem here is that the latter
checks active_events and in case of it being zero, exits without calling
the actual x86_pmu.handle_nmi(), which results in unknown NMI errors and
massive data loss for PT.

The effect is not visible if there are other perf events in the system
at the same time that keep active_events counter non-zero, for instance
if the NMI watchdog is running, so one needs to disable it to reproduce
the problem.

However, we have the lbr_exclusive[] counter for PT, so we can check that
for presence of PT events.

This patch adjusts perf_event_nmi_handler() to check for presence of
events in lbr_exclusive counter for PT in addition to checking
active_events counter.

Signed-off-by: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
---
 arch/x86/kernel/cpu/perf_event.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 8487714da2..cf066fc38c 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1426,7 +1426,23 @@ perf_event_nmi_handler(unsigned int cmd, struct pt_regs *regs)
 	u64 finish_clock;
 	int ret;

-	if (!atomic_read(&active_events))
+	/*
+	 * Intel PT is a separate PMUs, it doesn't increment active_events
+	 * nor does it use resources associated with it, such as DS area.
+	 * However, it still uses the same PMI handler, so here we need
+	 * to make sure to call it *also* if any PT events are present.
+	 *
+	 * BTS events currently increment active_events implicitly through
+	 * x86_reserve_hardware(), where it acts as DS area reference
+	 * counter, so no need to check x86_lbr_exclusive_bts counter here;
+	 * otherwise we'd have to do the same for BTS.
+	 *
+	 * Theoretically, they could be made into separate PMI handlers, but
+	 * that can create additional challenges as PT uses the same PMI status
+	 * register as x86_pmu.
+	 */
+	if (!atomic_read(&active_events) &&
+	    !atomic_read(&x86_pmu.lbr_exclusive[x86_lbr_exclusive_pt]))
 		return NMI_DONE;

 	start_clock = sched_clock();
-- 
2.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/