From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Erik Bosman <ebn310@few.vu.nl>, "H. Peter Anvin" <hpa@zytor.com>,
Linux API <linux-api@vger.kernel.org>,
Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
X86 ML <x86@kernel.org>
Subject: Re: [PATCH] x86,seccomp,prctl: Remove PR_TSC_SIGSEGV and seccomp TSC filtering
Date: Fri, 3 Oct 2014 23:02:13 +0200 [thread overview]
Message-ID: <20141003210213.GG6324@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20141003204443.GP10583@worktop.programming.kicks-ass.net>
On Fri, Oct 03, 2014 at 10:44:43PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 03, 2014 at 01:27:52PM -0700, Andy Lutomirski wrote:
> > On Fri, Oct 3, 2014 at 1:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > >
> > > We could make the rule be that RDPMC is enabled if a perf event is
> > > mmapped or TIF_SECCOMP is clear, but I'd prefer to be convinced that
> > > there's an actual performance issue first. Ideally we can get this
> > > all working with no API or ABI change at all.
> >
> > No, we can't use that rule. But we could say that RDPMC is enabled if
> > a perf event is mmapped and no thread in the mm uses seccomp. I'll
> > grumble a little bit about adding yet another piece of seccomp state.
>
> Well, we could simply disable the RDPMC for everything TIF_SECCOMP.
> Should be fairly straight fwd.
Something like so.. slightly less ugly and possibly with more
complicated conditions setting the cr4 if you want to fix tsc vs seccomp
as well.
---
arch/x86/kernel/cpu/perf_event.c | 13 ++++++++++++-
arch/x86/kernel/process.c | 24 +++++++++++++++++-------
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 16c73022306e..cfc42ff5d901 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1869,6 +1869,17 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+void perf_change_rdpmc(bool on, unsigned long *cr4)
+{
+ if (x86_pmu.attr_rdpmc_broken)
+ return;
+
+ if (on)
+ *cr4 |= X86_CR4_PCE;
+ else
+ *cr4 &= ~X86_CR4_PCE;
+}
+
static DEVICE_ATTR(rdpmc, S_IRUSR | S_IWUSR, get_attr_rdpmc, set_attr_rdpmc);
static struct attribute *x86_pmu_attrs[] = {
@@ -1928,7 +1939,7 @@ void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
userpg->cap_user_time = 0;
userpg->cap_user_time_zero = 0;
- userpg->cap_user_rdpmc = x86_pmu.attr_rdpmc;
+ userpg->cap_user_rdpmc = x86_pmu.attr_rdpmc && test_thread_flag(TIF_SECCOMP);
userpg->pmc_width = x86_pmu.cntval_bits;
if (!sched_clock_stable())
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e127ddaa2d5a..b74c0400851e 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -201,12 +201,15 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
struct tss_struct *tss)
{
struct thread_struct *prev, *next;
+ struct thread_info *pi, *ni;
prev = &prev_p->thread;
next = &next_p->thread;
- if (test_tsk_thread_flag(prev_p, TIF_BLOCKSTEP) ^
- test_tsk_thread_flag(next_p, TIF_BLOCKSTEP)) {
+ pi = task_thread_info(prev_p);
+ ni = task_thread_info(next_p);
+
+ if ((pi->flags & _TIF_BLOCKSTEP) ^ (ni->flags & _TIF_BLOCKSTEP)) {
unsigned long debugctl = get_debugctlmsr();
debugctl &= ~DEBUGCTLMSR_BTF;
@@ -216,13 +219,20 @@ void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
update_debugctlmsr(debugctl);
}
- if (test_tsk_thread_flag(prev_p, TIF_NOTSC) ^
- test_tsk_thread_flag(next_p, TIF_NOTSC)) {
+ if ((pi->flags & (_TIF_NOTSC | _TIF_SECCOMP)) ^
+ (ni->flags & (_TIF_NOTSC | _TIF_SECCOMP))) {
+ extern void perf_change_rdpmc(bool, unsigned long *);
+ unsigned long cr4 = read_cr4();
+
/* prev and next are different */
- if (test_tsk_thread_flag(next_p, TIF_NOTSC))
- hard_disable_TSC();
+ if (ni->flags & _TIF_NOTSC)
+ cr4 |= X86_CR4_TSD;
else
- hard_enable_TSC();
+ cr4 &= ~X86_CR4_TSD;
+
+ perf_change_rdpmc(!(ni->flags & _TIF_SECCOMP), &cr4);
+
+ write_cr4(cr4);
}
if (test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
next prev parent reply other threads:[~2014-10-03 21:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 17:18 Andy Lutomirski
2014-10-03 17:27 ` Andy Lutomirski
2014-10-03 20:14 ` Peter Zijlstra
2014-10-03 20:22 ` Andy Lutomirski
2014-10-03 20:27 ` Andy Lutomirski
2014-10-03 20:44 ` Peter Zijlstra
2014-10-03 20:46 ` Andy Lutomirski
2014-10-03 21:02 ` Peter Zijlstra [this message]
2014-10-03 21:04 ` Peter Zijlstra
2014-10-03 21:04 ` Andy Lutomirski
2014-10-03 21:12 ` Peter Zijlstra
2014-10-03 21:15 ` Andy Lutomirski
2014-10-04 8:13 ` Peter Zijlstra
2014-10-06 16:44 ` Andy Lutomirski
2014-10-03 20:42 ` Peter Zijlstra
2014-10-03 20:53 ` Andy Lutomirski
[not found] ` <20141003174141.GR2342@redhat.com>
2014-10-03 17:59 ` Andy Lutomirski
2014-10-03 20:15 ` Peter Zijlstra
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=20141003210213.GG6324@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aarcange@redhat.com \
--cc=acme@kernel.org \
--cc=ebn310@few.vu.nl \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=paulus@samba.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome