Message-ID: <aDN4nC6p93nK7ILVP3EH-Y4RcKK4KH0ppQKFkIgxTVxkfbOHWjAYJXdTeuq39nbPkySKItZ_8VHN2PfQS_T08GBzeooD5cvc2Xd8oZxSp9s=@protonmail.ch>
Date:   Mon, 19 Nov 2018 10:35:59 +0000
From:   Jordan Glover <Golden_Miller83@...tonmail.ch>
To:     Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Kees Cook <keescook@...omium.org>,
        Jann Horn <jannh@...gle.com>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Jonatan Corbet <corbet@....net>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Tvrtko Ursulin <tursulin@...ulin.net>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

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

Powered by blists - more mailing lists