[PATCH v1 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation

[PATCH v1 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation

[Alexey Budankov]

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

[PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst

[Alexey Budankov]

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 <alexey.budankov@linux.intel.com>
---
 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

[PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

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 <tglx@linutronix.de>
Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
---
 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/>`_
+

Re: [PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst

[Greg KH]

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 <alexey.budankov@linux.intel.com>
> ---
>  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 :(

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Peter Zijlstra]

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/094556ca-ea87-9c4a-2115-600d2833fb2a@darmarit.de

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Jordan Glover]

On Monday, November 19, 2018 6:42 AM, Alexey Budankov <alexey.budankov@linux.intel.com> 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 tglx@linutronix.de
> Signed-off-by: Alexey Budankov alexey.budankov@linux.intel.com
>
> 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

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Peter Zijlstra]

On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
> On Monday, November 19, 2018 6:42 AM, Alexey Budankov <alexey.budankov@linux.intel.com> 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.

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Jordan Glover]

On Monday, November 19, 2018 11:46 AM, Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
>
> > On Monday, November 19, 2018 6:42 AM, Alexey Budankov alexey.budankov@linux.intel.com 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

Re: [PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst

[Alexey Budankov]

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 <alexey.budankov@linux.intel.com>
>> ---
>>  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/>`_
+

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

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/094556ca-ea87-9c4a-2115-600d2833fb2a@darmarit.de
> 

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

Hi,

On 19.11.2018 13:49, Jordan Glover wrote:
> On Monday, November 19, 2018 11:46 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Mon, Nov 19, 2018 at 10:35:59AM +0000, Jordan Glover wrote:
>>
>>> On Monday, November 19, 2018 6:42 AM, Alexey Budankov alexey.budankov@linux.intel.com 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
> 
> 

Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

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/094556ca-ea87-9c4a-2115-600d2833fb2a@darmarit.de
> 

Addressed. Please see v4.

Thanks,
Alexey