perf-security.rst 12 KB

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