PAPI Forum

Dear members,
Due to the security vulnerability CVE-2013-2094 the perf_event_paranoid should be set to 2 but, according to the perf documentation,

Code: Select all

kernel.perf_event_paranoid = 2: you can't take any measurements. The perf utility might still be useful to analyse existing records with perf ls, perf report, perf timechart or perf trace.
kernel.perf_event_paranoid = 1: you can trace a command with perf stat or perf record, and get kernel profiling data.
kernel.perf_event_paranoid = 0: you can trace a command with perf stat or perf record, and get CPU event data.
kernel.perf_event_paranoid = -1: you get raw access to kernel tracepoints (specifically, you can mmap the file created by perf_event_open, I don't know what the implications are).


we are not going to be able to take any measurements.

If I configure like:

Code: Select all

./configure --with-pfm-incdir=libpfm4/include


After compiling and installing, if I try to run the papi_avail, I get:

Code: Select all

Of 108 possible events, 0 are available, of which 0 are derived.


and with strace:

Code: Select all

open("/proc/sys/kernel/perf_event_paranoid", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aba81940000
read(3, "2\n", 1024)                    = 2
close(3)                                = 0


It means, PAPI still tries to open /proc/sys/kernel/perf_event_paranoid.

My question here is, how can be have a PAPI compilation which does not use perf?
Thanks a lot in advance!!

You need to choose how paranoid you want to be.
If you want to use perf to measure performance counters with PAPI, perf_event_paranoid must be set to at most 0.
If you want to measure uncore events, perf_event_paranoid must be set to -1.
If you feel that your system is particularly vulnerable to this form of security breach, set perf_event_paranoid to 2 and don't use PAPI.

Thanks for your answer.
Does it really mean that there is no "substitute" for perf? I thought that we could use pfm instead...
At the moment, our system is completely vulnerably to this security breach and, at the moment, the solution (for the vulnerability) is to set the paranoid to 2.

[quote="cnavarrete"]
Due to the security vulnerability CVE-2013-2094 the perf_event_paranoid should be set to 2 but, according to the perf documentation,

Code: Select all

kernel.perf_event_paranoid = 2: you can't take any measurements. The perf utility might still be useful to analyse existing records with perf ls, perf report, perf timechart or perf trace.
kernel.perf_event_paranoid = 1: you can trace a command with perf stat or perf record, and get kernel profiling data.
kernel.perf_event_paranoid = 0: you can trace a command with perf stat or perf record, and get CPU event data.
kernel.perf_event_paranoid = -1: you get raw access to kernel tracepoints (specifically, you can mmap the file created by perf_event_open, I don't know what the implications are).


we are not going to be able to take any measurements.
[\quote]
Where specifically are you getting that description for paranoid = 2?
Most places I've seen it as
/*
* perf event paranoia level:
* -1 - not paranoid at all
* 0 - disallow raw tracepoint access for unpriv
* 1 - disallow cpu events for unpriv
* 2 - disallow kernel profiling for unpriv
*/

Meaning that you can only measure in user space.
Testing on several Fedora 3.6 and 3.7 kernels under paranoid level 2 bore this out.

$ cat /proc/sys/kernel/perf_event_paranoid
2
$ perf stat -e cpu-cycles ls
Error:
You may not have permission to collect %sstats.
Consider tweaking /proc/sys/kernel/perf_event_paranoid:
-1 - Not paranoid at all
0 - Disallow raw tracepoint access for unpriv
1 - Disallow cpu events for unpriv
2 - Disallow kernel profiling for unpriv
]$ perf stat -e cpu-cycles:u ls
core.c Makefile

Performance counter stats for 'ls':

528,414 cpu-cycles:u # 0.000 GHz

0.001572381 seconds time elapsed