Loading...
Note: File does not exist in v3.1.
1.. _perf_security:
2
3Perf Events and tool security
4=============================
5
6Overview
7--------
8
9Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_
10can impose a considerable risk of leaking sensitive data accessed by
11monitored processes. The data leakage is possible both in scenarios of
12direct usage of perf_events system call API [2]_ and over data files
13generated by Perf tool user mode utility (Perf) [3]_ , [4]_ . The risk
14depends on the nature of data that perf_events performance monitoring
15units (PMU) [2]_ and Perf collect and expose for performance analysis.
16Collected system and performance data may be split into several
17categories:
18
191. System hardware and software configuration data, for example: a CPU
20 model and its cache configuration, an amount of available memory and
21 its topology, used kernel and Perf versions, performance monitoring
22 setup including experiment time, events configuration, Perf command
23 line parameters, etc.
24
252. User and kernel module paths and their load addresses with sizes,
26 process and thread names with their PIDs and TIDs, timestamps for
27 captured hardware and software events.
28
293. Content of kernel software counters (e.g., for context switches, page
30 faults, CPU migrations), architectural hardware performance counters
31 (PMC) [8]_ and machine specific registers (MSR) [9]_ that provide
32 execution metrics for various monitored parts of the system (e.g.,
33 memory controller (IMC), interconnect (QPI/UPI) or peripheral (PCIe)
34 uncore counters) without direct attribution to any execution context
35 state.
36
374. Content of architectural execution context registers (e.g., RIP, RSP,
38 RBP on x86_64), process user and kernel space memory addresses and
39 data, content of various architectural MSRs that capture data from
40 this category.
41
42Data that belong to the fourth category can potentially contain
43sensitive process data. If PMUs in some monitoring modes capture values
44of execution context registers or data from process memory then access
45to such monitoring capabilities requires to be ordered and secured
46properly. So, perf_events/Perf performance monitoring is the subject for
47security access control management [5]_ .
48
49perf_events/Perf access control
50-------------------------------
51
52To perform security checks, the Linux implementation splits processes
53into two categories [6]_ : a) privileged processes (whose effective user
54ID is 0, referred to as superuser or root), and b) unprivileged
55processes (whose effective UID is nonzero). Privileged processes bypass
56all kernel security permission checks so perf_events performance
57monitoring is fully available to privileged processes without access,
58scope and resource restrictions.
59
60Unprivileged processes are subject to a full security permission check
61based on the process's credentials [5]_ (usually: effective UID,
62effective GID, and supplementary group list).
63
64Linux divides the privileges traditionally associated with superuser
65into distinct units, known as capabilities [6]_ , which can be
66independently enabled and disabled on per-thread basis for processes and
67files of unprivileged users.
68
69Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated
70as privileged processes with respect to perf_events performance
71monitoring and bypass *scope* permissions checks in the kernel.
72
73Unprivileged processes using perf_events system call API is also subject
74for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose
75outcome determines whether monitoring is permitted. So unprivileged
76processes provided with CAP_SYS_PTRACE capability are effectively
77permitted to pass the check.
78
79Other capabilities being granted to unprivileged processes can
80effectively enable capturing of additional data required for later
81performance analysis of monitored processes or a system. For example,
82CAP_SYSLOG capability permits reading kernel space memory addresses from
83/proc/kallsyms file.
84
85perf_events/Perf privileged users
86---------------------------------
87
88Mechanisms of capabilities, privileged capability-dumb files [6]_ and
89file system ACLs [10]_ can be used to create a dedicated group of
90perf_events/Perf privileged users who are permitted to execute
91performance monitoring without scope limits. The following steps can be
92taken to create such a group of privileged Perf users.
93
941. Create perf_users group of privileged Perf users, assign perf_users
95 group to Perf tool executable and limit access to the executable for
96 other users in the system who are not in the perf_users group:
97
98::
99
100 # groupadd perf_users
101 # ls -alhF
102 -rwxr-xr-x 2 root root 11M Oct 19 15:12 perf
103 # chgrp perf_users perf
104 # ls -alhF
105 -rwxr-xr-x 2 root perf_users 11M Oct 19 15:12 perf
106 # chmod o-rwx perf
107 # ls -alhF
108 -rwxr-x--- 2 root perf_users 11M Oct 19 15:12 perf
109
1102. Assign the required capabilities to the Perf tool executable file and
111 enable members of perf_users group with performance monitoring
112 privileges [6]_ :
113
114::
115
116 # setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
117 # setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
118 perf: OK
119 # getcap perf
120 perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
121
122As a result, members of perf_users group are capable of conducting
123performance monitoring by using functionality of the configured Perf
124tool executable that, when executes, passes perf_events subsystem scope
125checks.
126
127This specific access control management is only available to superuser
128or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_
129capabilities.
130
131perf_events/Perf unprivileged users
132-----------------------------------
133
134perf_events/Perf *scope* and *access* control for unprivileged processes
135is governed by perf_event_paranoid [2]_ setting:
136
137-1:
138 Impose no *scope* and *access* restrictions on using perf_events
139 performance monitoring. Per-user per-cpu perf_event_mlock_kb [2]_
140 locking limit is ignored when allocating memory buffers for storing
141 performance data. This is the least secure mode since allowed
142 monitored *scope* is maximized and no perf_events specific limits
143 are imposed on *resources* allocated for performance monitoring.
144
145>=0:
146 *scope* includes per-process and system wide performance monitoring
147 but excludes raw tracepoints and ftrace function tracepoints
148 monitoring. CPU and system events happened when executing either in
149 user or in kernel space can be monitored and captured for later
150 analysis. Per-user per-cpu perf_event_mlock_kb locking limit is
151 imposed but ignored for unprivileged processes with CAP_IPC_LOCK
152 [6]_ capability.
153
154>=1:
155 *scope* includes per-process performance monitoring only and
156 excludes system wide performance monitoring. CPU and system events
157 happened when executing either in user or in kernel space can be
158 monitored and captured for later analysis. Per-user per-cpu
159 perf_event_mlock_kb locking limit is imposed but ignored for
160 unprivileged processes with CAP_IPC_LOCK capability.
161
162>=2:
163 *scope* includes per-process performance monitoring only. CPU and
164 system events happened when executing in user space only can be
165 monitored and captured for later analysis. Per-user per-cpu
166 perf_event_mlock_kb locking limit is imposed but ignored for
167 unprivileged processes with CAP_IPC_LOCK capability.
168
169perf_events/Perf resource control
170---------------------------------
171
172Open file descriptors
173+++++++++++++++++++++
174
175The perf_events system call API [2]_ allocates file descriptors for
176every configured PMU event. Open file descriptors are a per-process
177accountable resource governed by the RLIMIT_NOFILE [11]_ limit
178(ulimit -n), which is usually derived from the login shell process. When
179configuring Perf collection for a long list of events on a large server
180system, this limit can be easily hit preventing required monitoring
181configuration. RLIMIT_NOFILE limit can be increased on per-user basis
182modifying content of the limits.conf file [12]_ . Ordinarily, a Perf
183sampling session (perf record) requires an amount of open perf_event
184file descriptors that is not less than the number of monitored events
185multiplied by the number of monitored CPUs.
186
187Memory allocation
188+++++++++++++++++
189
190The amount of memory available to user processes for capturing
191performance monitoring data is governed by the perf_event_mlock_kb [2]_
192setting. This perf_event specific resource setting defines overall
193per-cpu limits of memory allowed for mapping by the user processes to
194execute performance monitoring. The setting essentially extends the
195RLIMIT_MEMLOCK [11]_ limit, but only for memory regions mapped
196specifically for capturing monitored performance events and related data.
197
198For example, if a machine has eight cores and perf_event_mlock_kb limit
199is set to 516 KiB, then a user process is provided with 516 KiB * 8 =
2004128 KiB of memory above the RLIMIT_MEMLOCK limit (ulimit -l) for
201perf_event mmap buffers. In particular, this means that, if the user
202wants to start two or more performance monitoring processes, the user is
203required to manually distribute the available 4128 KiB between the
204monitoring processes, for example, using the --mmap-pages Perf record
205mode option. Otherwise, the first started performance monitoring process
206allocates all available 4128 KiB and the other processes will fail to
207proceed due to the lack of memory.
208
209RLIMIT_MEMLOCK and perf_event_mlock_kb resource constraints are ignored
210for processes with the CAP_IPC_LOCK capability. Thus, perf_events/Perf
211privileged users can be provided with memory above the constraints for
212perf_events/Perf performance monitoring purpose by providing the Perf
213executable with CAP_IPC_LOCK capability.
214
215Bibliography
216------------
217
218.. [1] `<https://lwn.net/Articles/337493/>`_
219.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_
220.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_
221.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_
222.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
223.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
224.. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
225.. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_
226.. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_
227.. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_
228.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
229.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_
230