12

I'd like to use the perf utility to gather measurements for my program. It runs on a shared cluster machine with Debian 9 where by default the /proc/sys/kernel/perf_event_paranoid is set to 3, therefore disallowing me to gather measurements. Before changing it, I'd like to know what the implications of this are.

Is it just security that would allow other users to profile stuff run by other uses and therefore gain insights? We do not care about this as it is a inner circle of users anyway. Or is it performance perhaps, which will impact everyone else as well?

Martin Ueding
  • 2,682
  • 3
  • 31
  • 45

1 Answers1

14

It’s only security, performance isn’t affected (at least, when perf isn’t running; and even then, perf’s impact is supposed to be minimal). Changing perf_event_paranoid doesn’t change the performance characteristics of the system, whether perf is running or not.

There’s a detailed discussion of the security implications of perf in the kernel documentation. The recommendation there is to set up a group for users with access to perf, and set perf up with the appropriate capabilities for that group, instead of changing perf_event_paranoid:

cd /usr/bin
groupadd perf_users
chgrp perf_users perf
chmod o-rwx perf
setcap cap_sys_admin,cap_sys_ptrace,cap_syslog=ep perf

and add yourself to the perf_users group.

Version 5.8 of the kernel added a dedicated capability, so instead of granting all of cap_sys_admin, the last command can be reduced to

setcap cap_perfmon,cap_sys_ptrace,cap_syslog=ep perf
Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 4
    It should be noted on some Linux distributions (e.g. Ubuntu 18.04LTS) `/usr/bin/perf` is actually a `bash` script which calls the "real" `perf` binary for the current kernel. In order to get this to work in such cases you'll need to set the capabilities on that instead. – PicoutputCls Aug 19 '21 at 09:00