All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Erik Bosman <ebn310@few.vu.nl>
Subject: Re: [RFC 5/5] x86,perf: Only allow rdpmc if a perf_event is mapped
Date: Thu, 16 Oct 2014 10:42:27 +0200	[thread overview]
Message-ID: <20141016084227.GI7369@worktop.fdxtended.com> (raw)
In-Reply-To: <b6c264b3bb064658af498763e234e3cb4f9db4e2.1413323612.git.luto@amacapital.net>

On Tue, Oct 14, 2014 at 03:57:39PM -0700, Andy Lutomirski wrote:
> We currently allow any process to use rdpmc.  This significantly
> weakens the protection offered by PR_TSC_DISABLED, and it could be
> helpful to users attempting to exploit timing attacks.
> 
> Since we can't enable access to individual counters, use a very
> coarse heuristic to limit access to rdpmc: allow access only when
> a perf_event is mmapped.  This protects seccomp sandboxes.
> 
> There is plenty of room to further tighen these restrictions.  For
> example, on x86, *all* perf_event mappings set cap_user_rdpmc.  This
> should probably be changed to only apply to perf_events that are
> accessible using rdpmc.

So I suppose this patch is a little over engineered,

> @@ -1852,10 +1865,26 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
>  	if (x86_pmu.attr_rdpmc_broken)
>  		return -ENOTSUPP;
>  
> +	mutex_lock(&rdpmc_enable_mutex);
>  	if (!!val != !!x86_pmu.attr_rdpmc) {
> -		x86_pmu.attr_rdpmc = !!val;
> -		on_each_cpu(change_rdpmc, (void *)val, 1);
> +		if (val) {
> +			static_key_slow_inc(&rdpmc_enabled);
> +			on_each_cpu(refresh_pce, NULL, 1);
> +			smp_wmb();
> +			x86_pmu.attr_rdpmc = 1;
> +		} else {
> +			/*
> +			 * This direction can race against existing
> +			 * rdpmc-capable mappings.  Try our best regardless.
> +			 */
> +			x86_pmu.attr_rdpmc = 0;
> +			smp_wmb();
> +			static_key_slow_dec(&rdpmc_enabled);
> +			WARN_ON(static_key_true(&rdpmc_enabled));
> +			on_each_cpu(refresh_pce, NULL, 1);
> +		}
>  	}
> +	mutex_unlock(&rdpmc_enable_mutex);
>  
>  	return count;
>  }

why do you care about that rdpmc_enabled static key thing? Also you
should not expose static key control to userspace like this, they can
totally wreck the system. At the very least it should be
static_key_slow_dec_deferred() -- gawd I hate the static_key API.

  reply	other threads:[~2014-10-16  8:42 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 22:57 [RFC 0/5] CR4 handling improvements Andy Lutomirski
2014-10-14 22:57 ` [RFC 1/5] x86: Clean up cr4 manipulation Andy Lutomirski
2014-10-16  8:16   ` Peter Zijlstra
2014-10-16 11:18     ` Borislav Petkov
2014-10-16 11:29       ` Borislav Petkov
2014-10-16 15:32         ` Andy Lutomirski
2014-10-16 15:47           ` Borislav Petkov
2014-10-14 22:57 ` [RFC 2/5] x86: Store a per-cpu shadow copy of CR4 Andy Lutomirski
2014-10-16  8:26   ` Peter Zijlstra
2014-10-16 11:49   ` Borislav Petkov
2014-10-16 15:30     ` Andy Lutomirski
2014-10-14 22:57 ` [RFC 3/5] x86: Add a comment clarifying LDT context switching Andy Lutomirski
2014-10-16 15:49   ` Borislav Petkov
2014-10-16 16:21     ` Andy Lutomirski
2014-10-21  5:41       ` Borislav Petkov
2014-10-21  5:44         ` Andy Lutomirski
2014-10-21  6:05           ` Borislav Petkov
2014-10-14 22:57 ` [RFC 4/5] perf: Add pmu callbacks to track event mapping and unmapping Andy Lutomirski
2014-10-14 22:57 ` [RFC 5/5] x86,perf: Only allow rdpmc if a perf_event is mapped Andy Lutomirski
2014-10-16  8:42   ` Peter Zijlstra [this message]
2014-10-16 15:37     ` Andy Lutomirski
2014-10-16 15:57     ` Borislav Petkov
2014-10-17  0:00   ` Andy Lutomirski
2014-10-19 20:23     ` Andy Lutomirski
2014-10-19 21:33       ` Peter Zijlstra
2014-10-19 22:05         ` Andy Lutomirski
2014-10-19 22:20           ` Peter Zijlstra
2014-10-19 22:57             ` Andy Lutomirski
2014-10-20  8:33               ` Peter Zijlstra
2014-10-20 16:49                 ` Andy Lutomirski
2014-10-20 17:39                   ` Andy Lutomirski
2014-10-21  8:59                     ` Peter Zijlstra
2014-10-19 21:35     ` Peter Zijlstra
2014-10-20  0:08       ` Andy Lutomirski
2014-10-20  8:48         ` Peter Zijlstra
2014-10-20  9:24           ` Martin Schwidefsky
2014-10-20 10:51           ` Hendrik Brueckner
2014-10-21  9:14             ` Peter Zijlstra
2014-10-21 15:52               ` Andy Lutomirski
2014-10-21  4:06 ` [RFC 0/5] CR4 handling improvements Vince Weaver
2014-10-21  4:28   ` Andy Lutomirski
2014-10-21 15:00     ` Vince Weaver
2014-10-21 16:04       ` Peter Zijlstra
2014-10-21 17:05         ` Vince Weaver
2014-10-23 11:42           ` Peter Zijlstra
2014-10-24 12:41             ` Vince Weaver
2014-10-24 22:14               ` Andy Lutomirski

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=20141016084227.GI7369@worktop.fdxtended.com \
    --to=peterz@infradead.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=aarcange@redhat.com \
    --cc=acme@kernel.org \
    --cc=ebn310@few.vu.nl \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    /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.