All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Glover <Golden_Miller83@protonmail.ch>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andi Kleen <ak@linux.intel.com>, Jonatan Corbet <corbet@lwn.net>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file
Date: Mon, 19 Nov 2018 10:35:59 +0000	[thread overview]
Message-ID: <aDN4nC6p93nK7ILVP3EH-Y4RcKK4KH0ppQKFkIgxTVxkfbOHWjAYJXdTeuq39nbPkySKItZ_8VHN2PfQS_T08GBzeooD5cvc2Xd8oZxSp9s=@protonmail.ch> (raw)
In-Reply-To: <a44df303-d962-c1a4-4fe0-6bad887ebcdc@linux.intel.com>

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

  parent reply	other threads:[~2018-11-19 10:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19  5:37 [PATCH v1 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation Alexey Budankov
2018-11-19  5:41 ` [PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst Alexey Budankov
2018-11-19 10:03   ` Greg KH
2018-11-19 15:12     ` Alexey Budankov
2018-11-19  5:42 ` [PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file Alexey Budankov
2018-11-19 10:33   ` Peter Zijlstra
2018-11-19 15:13     ` Alexey Budankov
2018-11-27  8:17     ` Alexey Budankov
2018-11-19 10:35   ` Jordan Glover [this message]
2018-11-19 10:35     ` Jordan Glover
2018-11-19 10:46     ` Peter Zijlstra
2018-11-19 10:46       ` Peter Zijlstra
2018-11-19 10:49       ` Jordan Glover
2018-11-19 10:49         ` Jordan Glover
2018-11-19 15:19         ` Alexey Budankov
2018-11-19 15:19           ` Alexey Budankov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='aDN4nC6p93nK7ILVP3EH-Y4RcKK4KH0ppQKFkIgxTVxkfbOHWjAYJXdTeuq39nbPkySKItZ_8VHN2PfQS_T08GBzeooD5cvc2Xd8oZxSp9s=@protonmail.ch' \
    --to=golden_miller83@protonmail.ch \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=jannh@google.com \
    --cc=jolsa@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tursulin@ursulin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.