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  
> wrote:
> 
>> On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
>>
>>> On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
>>> alexey.budan...@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:49, Jordan Glover wrote:
> On Monday, November 19, 2018 11:46 AM, Peter Zijlstra  
> wrote:
> 
>> On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
>>
>>> On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
>>> alexey.budan...@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.

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-600d2833f...@darmarit.de
> 

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-600d2833f...@darmarit.de
> 

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  
wrote:

> On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
>
> > On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
> > alexey.budan...@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 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Jordan Glover]

On Monday, November 19, 2018 11:46 AM, Peter Zijlstra  
wrote:

> On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
>
> > On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
> > alexey.budan...@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 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Peter Zijlstra]

On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
> On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
>  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

[Peter Zijlstra]

On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
> On Monday, November 19, 2018 6:42 AM, Alexey Budankov 
>  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 6:42 AM, 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.
>
> Suggested-by: Thomas Gleixner t...@linutronix.de
> Signed-off-by: Alexey Budankov alexey.budan...@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 ..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

[Jordan Glover]

On Monday, November 19, 2018 6:42 AM, 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.
>
> Suggested-by: Thomas Gleixner t...@linutronix.de
> Signed-off-by: Alexey Budankov alexey.budan...@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 ..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 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-600d2833f...@darmarit.de

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-600d2833f...@darmarit.de

[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 
Signed-off-by: Alexey Budankov 
---
 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 ..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] ``_
+.. [2] ``_
+.. [3] ``_
+.. [4] ``_
+.. [5] ``_
+.. [6] ``_
+.. [7] ``_
+.. [8] ``_
+

[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 
Signed-off-by: Alexey Budankov 
---
 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 ..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] ``_
+.. [2] ``_
+.. [3] ``_
+.. [4] ``_
+.. [5] ``_
+.. [6] ``_
+.. [7] ``_
+.. [8] ``_
+