Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 1 Oct 2018 09:27:07 +0300
From: Alexey Budankov <>
To: Jann Horn <>, Kees Cook <>
Cc:, Thomas Gleixner <>,, kernel list <>,
 Peter Zijlstra <>,
 the arch/x86 maintainers <>, "H . Peter Anvin"
 Andi Kleen <>,
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

Hello Jann and Kees,

On 29.09.2018 1:02, Jann Horn wrote:
> Ah, I guess the answer is "0", since you want to see data about what
> other users are doing.
> Does the i915 PMU expose sampling events, counting events, or both?
> The thing about sampling events is that they AFAIK always let the user
> pick arbitrary data to collect - like register contents, or userspace
> stack memory -, and independent of the performance counter being
> monitored, this kind of access should not be permitted to other
> contexts. (But it might be that I misunderstand how perf works - I'm
> not super familiar with its API.)

Currently *core* paranoid >= 1 (per-process mode) prevents simultaneous 
sampling on CPU events (perf record) and reading of uncore HW counters 
(perf stat -I), because uncore counters count system wide and that is 
allowed only when *core* paranoid <= 0.

Uncore counts collected simultaneously with CPU event samples can be 
correlated using timestamps taken from some common system clock e.g. 

Could it be secure enough to still allow reading of system wide uncore 
HW counters when sampling of CPU events is limited to specific processes 
by *core* paranoid >= 1?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.