To facilitate informed decision making by system administrators [1]
to permit and manage access to PCL/Perf [2],[3] performance monitoring
for multiple users perf-security.rst document suggested by Thomas Gleixner
is introduced [4] that:
a) states PCL/Perf access security concerns for multi user environment
b) refers to base Linux access control and management principles
c) extends documentation of possible perf_event_paranoid knob settings
The file serves as single knowledge source for PCL/Perf security and
access control related matter according to decisions, discussion and
PoC prototype previously made here [5],[6].
The file can later be extended with information describing:
a) PCL/Perf usage models and its security implications
b) PCL/Perf user interface, its changes and related security implications
c) security related implications of monitoring by a specific PCL PMU [2]
---
Alexey Budankov (2):
Documentation/admin-guide: update admin-guide index.rst
Documentation/admin-guide: introduce perf-security.rst file
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/perf-security.rst | 83 +++++++++++++++++++++++++++++
2 files changed, 84 insertions(+)
---
[1] https://marc.info/?l=linux-kernel&m=153815883923913&w=2
[2] http://man7.org/linux/man-pages/man2/perf_event_open.2.html
[3] https://perf.wiki.kernel.org/index.php/Main_Page
[4] https://marc.info/?l=linux-kernel&m=153837512226838&w=2
[5] https://marc.info/?l=linux-kernel&m=153736008310781&w=2
[6] https://lkml.org/lkml/2018/5/21/156
Extend index.rst index file at admin-guide root directory with
the reference to perf-security.rst file being introduced.
Signed-off-by: Alexey Budankov <[email protected]>
---
Documentation/admin-guide/index.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 0873685bab0f..885cc0de9114 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
thunderbolt
LSM/index
mm/index
+ perf-security
.. only:: subproject and html
Implement initial version of perf-security.rst documentation file
initially covering security concerns related to PCL/Perf performance
monitoring in multiuser environments.
Suggested-by: Thomas Gleixner <[email protected]>
Signed-off-by: Alexey Budankov <[email protected]>
---
Documentation/admin-guide/perf-security.rst | 83 +++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
new file mode 100644
index 000000000000..b9564066e686
--- /dev/null
+++ b/Documentation/admin-guide/perf-security.rst
@@ -0,0 +1,83 @@
+.. _perf_security:
+
+PCL/Perf security
+=================
+
+Overview
+--------
+
+Usage of Performance Counters for Linux (PCL) [1]_ , [2]_ , [3]_ can impose a
+considerable risk of leaking sensitive data accessed by monitored processes.
+The data leakage is possible both in scenarios of direct usage of PCL system
+call API [2]_ and over data files generated by Perf tool user mode utility
+(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL performance
+monitoring units (PMU) [2]_ collect and expose for performance analysis.
+Having that said PCL/Perf performance monitoring is the subject for security
+access control management [5]_ .
+
+PCL/Perf access control
+-----------------------
+
+For the purpose of performing security checks Linux implementation splits
+processes into two categories [6]_ : a) privileged processes (whose effective
+user ID is 0, referred to as superuser or root), and b) unprivileged processes
+(whose effective UID is nonzero). Privileged processes bypass all kernel
+security permission checks so PCL performance monitoring is fully available to
+privileged processes without *access*, *scope* and *resource* restrictions.
+Unprivileged processes are subject to full security permission check based
+on the process's credentials [5]_ (usually: effective UID, effective GID,
+and supplementary group list).
+
+PCL/Perf unprivileged users
+---------------------------
+
+PCL/Perf *scope* and *access* control for unprivileged processes is governed by
+perf_event_paranoid [2]_ setting:
+
+**-1**:
+ Impose no *scope* and *access* restrictions on using PCL performance
+ monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
+ ignored when allocating memory buffers for storing performance data.
+ This is the least secure mode since allowed monitored *scope* is
+ maximized and no PCL specific limits are imposed on *resources*
+ allocated for performance monitoring.
+
+**>=0**:
+ *scope* includes per-process and system wide performance monitoring
+ but excludes raw tracepoints and ftrace function tracepoints monitoring.
+ CPU and system events happened when executing either in user or
+ in kernel space can be monitored and captured for later analysis.
+ Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
+ ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
+
+**>=1**:
+ *scope* includes per-process performance monitoring only and excludes
+ system wide performance monitoring. CPU and system events happened when
+ executing either in user or in kernel space can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=2**:
+ *scope* includes per-process performance monitoring only. CPU and system
+ events happened when executing in user space only can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=3**:
+ Restrict *access* to PCL performance monitoring for unprivileged processes.
+ This is the default on Debian and Android [7]_ , [8]_ .
+
+Bibliography
+------------
+
+.. [1] `<https://lwn.net/Articles/337493/>`_
+.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_
+.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_
+.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_
+.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
+.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
+.. [7] `<https://lkml.org/lkml/2016/1/11/587>`_
+.. [8] `<https://android-review.googlesource.com/#/c/234743/>`_
+
On Mon, Nov 19, 2018 at 08:41:31AM +0300, Alexey Budankov wrote:
>
> Extend index.rst index file at admin-guide root directory with
> the reference to perf-security.rst file being introduced.
>
> Signed-off-by: Alexey Budankov <[email protected]>
> ---
> Documentation/admin-guide/index.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 0873685bab0f..885cc0de9114 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
> thunderbolt
> LSM/index
> mm/index
> + perf-security
You just broke the build with this patch. They need to be ordered the
other way around :(
On Mon, Nov 19, 2018 at 08:42:52AM +0300, Alexey Budankov wrote:
>
> Implement initial version of perf-security.rst documentation file
> initially covering security concerns related to PCL/Perf performance
> monitoring in multiuser environments.
Ditch the PCL thing. That's not a term used anywhere in the kernel.
Also:
> +PCL/Perf unprivileged users
> +---------------------------
> +
> +PCL/Perf *scope* and *access* control for unprivileged processes is governed by
> +perf_event_paranoid [2]_ setting:
> +
> +**-1**:
> + Impose no *scope* and *access* restrictions on using PCL performance
> + monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
> + ignored when allocating memory buffers for storing performance data.
> + This is the least secure mode since allowed monitored *scope* is
> + maximized and no PCL specific limits are imposed on *resources*
> + allocated for performance monitoring.
> +
> +**>=0**:
> + *scope* includes per-process and system wide performance monitoring
> + but excludes raw tracepoints and ftrace function tracepoints monitoring.
> + CPU and system events happened when executing either in user or
> + in kernel space can be monitored and captured for later analysis.
> + Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
> + ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
> +
> +**>=1**:
> + *scope* includes per-process performance monitoring only and excludes
> + system wide performance monitoring. CPU and system events happened when
> + executing either in user or in kernel space can be monitored and
> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
> + locking limit is imposed but ignored for unprivileged processes with
> + CAP_IPC_LOCK capability.
> +
> +**>=2**:
> + *scope* includes per-process performance monitoring only. CPU and system
> + events happened when executing in user space only can be monitored and
> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
> + locking limit is imposed but ignored for unprivileged processes with
> + CAP_IPC_LOCK capability.
> +
> +**>=3**:
> + Restrict *access* to PCL performance monitoring for unprivileged processes.
> + This is the default on Debian and Android [7]_ , [8]_ .
that ** crud is unreadable.
http://lkml.kernel.org/r/[email protected]
On Monday, November 19, 2018 6:42 AM, Alexey Budankov <[email protected]> wrote:
> Implement initial version of perf-security.rst documentation file
> initially covering security concerns related to PCL/Perf performance
> monitoring in multiuser environments.
>
> Suggested-by: Thomas Gleixner [email protected]
> Signed-off-by: Alexey Budankov [email protected]
>
> Documentation/admin-guide/perf-security.rst | 83 +++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
>
> diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
> new file mode 100644
> index 000000000000..b9564066e686
> --- /dev/null
> +++ b/Documentation/admin-guide/perf-security.rst
> @@ -0,0 +1,83 @@
> +.. perf_security:
> +
> +PCL/Perf security
> +=================
> +
> +Overview
> +--------
> +
> +Usage of Performance Counters for Linux (PCL) [1] , [2]_ , [3]_ can impose a+considerable risk of leaking sensitive data accessed by monitored processes.
> +The data leakage is possible both in scenarios of direct usage of PCL system
> +call API [2]_ and over data files generated by Perf tool user mode utility
> +(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL performance
> +monitoring units (PMU) [2]_ collect and expose for performance analysis.
> +Having that said PCL/Perf performance monitoring is the subject for security
> +access control management [5]_ .
> +
> +PCL/Perf access control
> +-----------------------
> +
> +For the purpose of performing security checks Linux implementation splits
> +processes into two categories [6]_ : a) privileged processes (whose effective
> +user ID is 0, referred to as superuser or root), and b) unprivileged processes
> +(whose effective UID is nonzero). Privileged processes bypass all kernel
> +security permission checks so PCL performance monitoring is fully available to
> +privileged processes without access, scope and resource restrictions.
> +Unprivileged processes are subject to full security permission check based
> +on the process's credentials [5]_ (usually: effective UID, effective GID,
> +and supplementary group list).
> +
> +PCL/Perf unprivileged users
> +---------------------------
> +
> +PCL/Perf scope and access control for unprivileged processes is governed by
> +perf_event_paranoid [2]_ setting:
> +
> +-1:
>
> - Impose no *scope* and *access* restrictions on using PCL performance
>
>
> - monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
>
>
> - ignored when allocating memory buffers for storing performance data.
>
>
> - This is the least secure mode since allowed monitored *scope* is
>
>
> - maximized and no PCL specific limits are imposed on *resources*
>
>
> - allocated for performance monitoring.
>
>
> -
>
> +>=0:
>
> - *scope* includes per-process and system wide performance monitoring
>
>
> - but excludes raw tracepoints and ftrace function tracepoints monitoring.
>
>
> - CPU and system events happened when executing either in user or
>
>
> - in kernel space can be monitored and captured for later analysis.
>
>
> - Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
>
>
> - ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
>
>
> -
>
> +>=1:
>
> - *scope* includes per-process performance monitoring only and excludes
>
>
> - system wide performance monitoring. CPU and system events happened when
>
>
> - executing either in user or in kernel space can be monitored and
>
>
> - captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>
>
> - locking limit is imposed but ignored for unprivileged processes with
>
>
> - CAP_IPC_LOCK capability.
>
>
> -
>
> +>=2:
>
> - *scope* includes per-process performance monitoring only. CPU and system
>
>
> - events happened when executing in user space only can be monitored and
>
>
> - captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>
>
> - locking limit is imposed but ignored for unprivileged processes with
>
>
> - CAP_IPC_LOCK capability.
>
>
> -
>
> +>=3:
>
> - Restrict *access* to PCL performance monitoring for unprivileged processes.
>
>
> - This is the default on Debian and Android [7]_ , [8]_ .
AFAIK there is no support for '+>=3' in mainline kernel[1].
Debian and Android use out-of-tree patch for that[2].
Maybe someone should upstream it?
Jordan
[1] https://github.com/torvalds/linux/blob/master/kernel/events/core.c#L395
[2] https://salsa.debian.org/kernel-team/linux/blob/master/debian/patches/features/all/security-perf-allow-further-restriction-of-perf_event_open.patch
On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
> On Monday, November 19, 2018 6:42 AM, Alexey Budankov <[email protected]> wrote:
> > +>=3:
> >
> > - Restrict *access* to PCL performance monitoring for unprivileged processes.
> >
> >
> > - This is the default on Debian and Android [7]_ , [8]_ .
>
> AFAIK there is no support for '+>=3' in mainline kernel[1].
> Debian and Android use out-of-tree patch for that[2].
> Maybe someone should upstream it?
NAK still stands on that. Alternative's have been proposed but so far
nobody that cared seems to care enough to implement those.
On Monday, November 19, 2018 11:46 AM, Peter Zijlstra <[email protected]> wrote:
> On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
>
> > On Monday, November 19, 2018 6:42 AM, Alexey Budankov [email protected] wrote:
> >
> > > +>=3:
> > >
> > > - Restrict *access* to PCL performance monitoring for unprivileged processes.
> > >
> > >
> > > - This is the default on Debian and Android [7]_ , [8]_ .
> > >
> > >
> >
> > AFAIK there is no support for '+>=3' in mainline kernel[1].
> > Debian and Android use out-of-tree patch for that[2].
> > Maybe someone should upstream it?
>
> NAK still stands on that. Alternative's have been proposed but so far
> nobody that cared seems to care enough to implement those.
So, I guess we can't document NAKed patches :)
Jordan
Hello Greg,
On 19.11.2018 13:03, Greg KH wrote:
> On Mon, Nov 19, 2018 at 08:41:31AM +0300, Alexey Budankov wrote:
>>
>> Extend index.rst index file at admin-guide root directory with
>> the reference to perf-security.rst file being introduced.
>>
>> Signed-off-by: Alexey Budankov <[email protected]>
>> ---
>> Documentation/admin-guide/index.rst | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
>> index 0873685bab0f..885cc0de9114 100644
>> --- a/Documentation/admin-guide/index.rst
>> +++ b/Documentation/admin-guide/index.rst
>> @@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
>> thunderbolt
>> LSM/index
>> mm/index
>> + perf-security
>
> You just broke the build with this patch. They need to be ordered the
> other way around :(
Thanks for pointing that out.
The patches are now rebased according to MAINTAINERS here:
git://git.lwn.net/linux.git docs-next
make htmldocs SPHINXDIRS=admin-guide worked for me:
...
build succeeded, 10 warnings.
The HTML pages are in Documentation/output/admin-guide.
firefox Documentation/output/admin-guide/index.html
shows link to the document at the end of this paragraph:
"The rest of this manual consists of various unordered guides on how to \
configure specific aspects of kernel behavior to your liking."
Rebased changes are below for your convenience.
Thanks,
Alexey
---
Documentation/admin-guide/index.rst | 1 +
Documentation/admin-guide/perf-security.rst | 83 +++++++++++++++++++++++++++++
2 files changed, 84 insertions(+)
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 965745d5fb9a..0a491676685e 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -76,6 +76,7 @@ configure specific aspects of kernel behavior to your liking.
thunderbolt
LSM/index
mm/index
+ perf-security
.. only:: subproject and html
diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst
new file mode 100644
index 000000000000..b9564066e686
--- /dev/null
+++ b/Documentation/admin-guide/perf-security.rst
@@ -0,0 +1,83 @@
+.. _perf_security:
+
+PCL/Perf security
+=================
+
+Overview
+--------
+
+Usage of Performance Counters for Linux (PCL) [1]_ , [2]_ , [3]_ can impose a
+considerable risk of leaking sensitive data accessed by monitored processes.
+The data leakage is possible both in scenarios of direct usage of PCL system
+call API [2]_ and over data files generated by Perf tool user mode utility
+(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL performance
+monitoring units (PMU) [2]_ collect and expose for performance analysis.
+Having that said PCL/Perf performance monitoring is the subject for security
+access control management [5]_ .
+
+PCL/Perf access control
+-----------------------
+
+For the purpose of performing security checks Linux implementation splits
+processes into two categories [6]_ : a) privileged processes (whose effective
+user ID is 0, referred to as superuser or root), and b) unprivileged processes
+(whose effective UID is nonzero). Privileged processes bypass all kernel
+security permission checks so PCL performance monitoring is fully available to
+privileged processes without *access*, *scope* and *resource* restrictions.
+Unprivileged processes are subject to full security permission check based
+on the process's credentials [5]_ (usually: effective UID, effective GID,
+and supplementary group list).
+
+PCL/Perf unprivileged users
+---------------------------
+
+PCL/Perf *scope* and *access* control for unprivileged processes is governed by
+perf_event_paranoid [2]_ setting:
+
+**-1**:
+ Impose no *scope* and *access* restrictions on using PCL performance
+ monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
+ ignored when allocating memory buffers for storing performance data.
+ This is the least secure mode since allowed monitored *scope* is
+ maximized and no PCL specific limits are imposed on *resources*
+ allocated for performance monitoring.
+
+**>=0**:
+ *scope* includes per-process and system wide performance monitoring
+ but excludes raw tracepoints and ftrace function tracepoints monitoring.
+ CPU and system events happened when executing either in user or
+ in kernel space can be monitored and captured for later analysis.
+ Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
+ ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
+
+**>=1**:
+ *scope* includes per-process performance monitoring only and excludes
+ system wide performance monitoring. CPU and system events happened when
+ executing either in user or in kernel space can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=2**:
+ *scope* includes per-process performance monitoring only. CPU and system
+ events happened when executing in user space only can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=3**:
+ Restrict *access* to PCL performance monitoring for unprivileged processes.
+ This is the default on Debian and Android [7]_ , [8]_ .
+
+Bibliography
+------------
+
+.. [1] `<https://lwn.net/Articles/337493/>`_
+.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_
+.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_
+.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_
+.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
+.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
+.. [7] `<https://lkml.org/lkml/2016/1/11/587>`_
+.. [8] `<https://android-review.googlesource.com/#/c/234743/>`_
+
Hi,
On 19.11.2018 13:33, Peter Zijlstra wrote:
> On Mon, Nov 19, 2018 at 08:42:52AM +0300, Alexey Budankov wrote:
>>
>> Implement initial version of perf-security.rst documentation file
>> initially covering security concerns related to PCL/Perf performance
>> monitoring in multiuser environments.
>
> Ditch the PCL thing. That's not a term used anywhere in the kernel.
Ok. Which is the proper wording to reference to Perf kernel subsystem?
>
> Also:
>
>> +PCL/Perf unprivileged users
>> +---------------------------
>> +
>> +PCL/Perf *scope* and *access* control for unprivileged processes is governed by
>> +perf_event_paranoid [2]_ setting:
>> +
>> +**-1**:
>> + Impose no *scope* and *access* restrictions on using PCL performance
>> + monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
>> + ignored when allocating memory buffers for storing performance data.
>> + This is the least secure mode since allowed monitored *scope* is
>> + maximized and no PCL specific limits are imposed on *resources*
>> + allocated for performance monitoring.
>> +
>> +**>=0**:
>> + *scope* includes per-process and system wide performance monitoring
>> + but excludes raw tracepoints and ftrace function tracepoints monitoring.
>> + CPU and system events happened when executing either in user or
>> + in kernel space can be monitored and captured for later analysis.
>> + Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
>> + ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
>> +
>> +**>=1**:
>> + *scope* includes per-process performance monitoring only and excludes
>> + system wide performance monitoring. CPU and system events happened when
>> + executing either in user or in kernel space can be monitored and
>> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>> + locking limit is imposed but ignored for unprivileged processes with
>> + CAP_IPC_LOCK capability.
>> +
>> +**>=2**:
>> + *scope* includes per-process performance monitoring only. CPU and system
>> + events happened when executing in user space only can be monitored and
>> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>> + locking limit is imposed but ignored for unprivileged processes with
>> + CAP_IPC_LOCK capability.
>> +
>> +**>=3**:
>> + Restrict *access* to PCL performance monitoring for unprivileged processes.
>> + This is the default on Debian and Android [7]_ , [8]_ .
>
> that ** crud is unreadable.
It can be avoided without missing the sense.
"two asterisks: **text** for strong emphasis (boldface)".
Thanks,
Alexey
>
> http://lkml.kernel.org/r/[email protected]
>
Hi,
On 19.11.2018 13:49, Jordan Glover wrote:
> On Monday, November 19, 2018 11:46 AM, Peter Zijlstra <[email protected]> wrote:
>
>> On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
>>
>>> On Monday, November 19, 2018 6:42 AM, Alexey Budankov [email protected] wrote:
>>>
>>>> +>=3:
>>>>
>>>> - Restrict *access* to PCL performance monitoring for unprivileged processes.
>>>>
>>>>
>>>> - This is the default on Debian and Android [7]_ , [8]_ .
>>>>
>>>>
>>>
>>> AFAIK there is no support for '+>=3' in mainline kernel[1].
>>> Debian and Android use out-of-tree patch for that[2].
>>> Maybe someone should upstream it?
>>
>> NAK still stands on that. Alternative's have been proposed but so far
>> nobody that cared seems to care enough to implement those.
>
> So, I guess we can't document NAKed patches :)
Please stay tuned for v2.
Thanks,
Alexey
>
> Jordan
>
>
Hi,
On 19.11.2018 13:33, Peter Zijlstra wrote:
> On Mon, Nov 19, 2018 at 08:42:52AM +0300, Alexey Budankov wrote:
>>
>> Implement initial version of perf-security.rst documentation file
>> initially covering security concerns related to PCL/Perf performance
>> monitoring in multiuser environments.
>
> Ditch the PCL thing. That's not a term used anywhere in the kernel.
Addressed. Please see v4.
>
> Also:
>
>> +PCL/Perf unprivileged users
>> +---------------------------
>> +
>> +PCL/Perf *scope* and *access* control for unprivileged processes is governed by
>> +perf_event_paranoid [2]_ setting:
>> +
>> +**-1**:
>> + Impose no *scope* and *access* restrictions on using PCL performance
>> + monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
>> + ignored when allocating memory buffers for storing performance data.
>> + This is the least secure mode since allowed monitored *scope* is
>> + maximized and no PCL specific limits are imposed on *resources*
>> + allocated for performance monitoring.
>> +
>> +**>=0**:
>> + *scope* includes per-process and system wide performance monitoring
>> + but excludes raw tracepoints and ftrace function tracepoints monitoring.
>> + CPU and system events happened when executing either in user or
>> + in kernel space can be monitored and captured for later analysis.
>> + Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
>> + ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
>> +
>> +**>=1**:
>> + *scope* includes per-process performance monitoring only and excludes
>> + system wide performance monitoring. CPU and system events happened when
>> + executing either in user or in kernel space can be monitored and
>> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>> + locking limit is imposed but ignored for unprivileged processes with
>> + CAP_IPC_LOCK capability.
>> +
>> +**>=2**:
>> + *scope* includes per-process performance monitoring only. CPU and system
>> + events happened when executing in user space only can be monitored and
>> + captured for later analysis. Per-user per-cpu perf_event_mlock_kb
>> + locking limit is imposed but ignored for unprivileged processes with
>> + CAP_IPC_LOCK capability.
>> +
>> +**>=3**:
>> + Restrict *access* to PCL performance monitoring for unprivileged processes.
>> + This is the default on Debian and Android [7]_ , [8]_ .
>
> that ** crud is unreadable.
>
> http://lkml.kernel.org/r/[email protected]
>
Addressed. Please see v4.
Thanks,
Alexey