linux-kernel - Re: [PATCH] perf/x86/pebs: fix handling of PEBS buffer overflows

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]

Message-ID: <20161222132523.GM3107@twins.programming.kicks-ass.net>
Date:   Thu, 22 Dec 2016 14:25:23 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Stephane Eranian <eranian@...gle.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...e.hu, ak@...ux.intel.com,
        vincent.weaver@...ne.edu
Subject: Re: [PATCH] perf/x86/pebs: fix handling of PEBS buffer overflows

On Thu, Dec 22, 2016 at 12:29:26AM -0800, Stephane Eranian wrote:
> This patch solves a race condition between PEBS and the PMU handler.
> 
> In case multiple PEBS events are sampled at the same time,
> it is possible to have GLOBAL_STATUS bit 62 set indicating
> PEBS buffer overflow and also seeing at most 3 PEBS counters
> having their bits set in the status register. This is a sign
> that there was at least one PEBS record pending at the time
> of the PMU interrupt. PEBS counters must only be processed
> via the drain_pebs() calls, and not via the regular sample
> processing loop coming after that the function, otherwise
> phony regular samples may be generated in the sampling buffer
> not marked with the EXACT tag.
> 
> Another possibility is to have one PEBS event and at least
> one non-PEBS event whic hoverflows while PEBS has armed. In this
> case, bit 62 of GLOBAL_STATUS will not be set, yet the overflow
> status bit for the PEBS counter will be on Skylake.
> 
> To avoid this problem, we systematically ignore the PEBS-enabled
> counters from the GLOBAL_STATUS mask and we always process PEBS
> events via drain_pebs().
> 
> The problem manifested itself by having non-exact samples when
> sampling only PEBS events, i.e., the PERF_SAMPLE_RECORD would
> not have the EXACT flag set.
> 
> Note that this problem is only present on Skylake processor.
> This fix is harmless on older processors.
> 
> Reported-by:  Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Stephane Eranian <eranian@...gle.com>
> ---

Thanks!