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: Sat, 4 Oct 2014 10:13:24 +0200 [thread overview]
Message-ID: <20141004081324.GR10583@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CALCETrVtK6w4smnRCTED=csAyt3WNNOaZE_WRzvECuSx260X3w@mail.gmail.com>
On Fri, Oct 03, 2014 at 02:15:24PM -0700, Andy Lutomirski wrote:
> On Fri, Oct 3, 2014 at 2:12 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Fri, Oct 03, 2014 at 02:04:53PM -0700, Andy Lutomirski wrote:
> >> On Fri, Oct 3, 2014 at 2:02 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >> > 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.
> >>
> >> This will crash anything that tries rdpmc in an allow-everything
> >> seccomp sandbox. It's also not very compatible with my grand scheme
> >> of allowing rdtsc to be turned off without breaking clock_gettime. :)
> >
> > Well, we clear cap_user_rdpmc, so everybody who still tries it gets what
> > he deserves, no problem there.
>
> Oh, interesting.
>
> To continue playing devil's advocate, what if you do perf_event_open,
> then mmap it, then start the seccomp sandbox?
We update that cap bit on every update to the self-monitor state, and in
a perfect world people would also check the cap bit every time they try
and read it, and fall back to the syscall. So we could just clear it..
but I can imagine reality ruining things here.
> My draft patches are currently tracking the number of perf_event mmaps
> per mm. I'm not thrilled with it, but it's straightforward. And I
> still need to benchmark cr4 writes, which is tedious, because I can't
> do it from user code.
Should be fairly straight fwd from kernel space, get a tsc stamp,
read+write cr4 1000 times, get another tsc read, and maybe do that
several times. No?
next prev parent reply other threads:[~2014-10-04 8:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 17:18 [PATCH] x86,seccomp,prctl: Remove PR_TSC_SIGSEGV and seccomp TSC filtering Andy Lutomirski
[not found] ` <fc0c2447cbc39257941c6b118388c024b719353a.1412356529.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2014-10-03 17:27 ` Andy Lutomirski
2014-10-03 17:27 ` Andy Lutomirski
[not found] ` <CALCETrUfCrvidOS6VvUpWFAcHUrPUs58zSQqGRC5UOTS=E37rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-03 20:14 ` Peter Zijlstra
2014-10-03 20:14 ` Peter Zijlstra
[not found] ` <20141003201409.GM10583-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-03 20:22 ` Andy Lutomirski
2014-10-03 20:22 ` Andy Lutomirski
2014-10-03 20:27 ` Andy Lutomirski
[not found] ` <CALCETrWfrWpdMCAYySMAMGCHU3XRkNGmeMTECTE=PXQUfjGPZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-03 20:44 ` Peter Zijlstra
2014-10-03 20:44 ` Peter Zijlstra
[not found] ` <20141003204443.GP10583-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-03 20:46 ` Andy Lutomirski
2014-10-03 20:46 ` Andy Lutomirski
2014-10-03 21:02 ` Peter Zijlstra
2014-10-03 21:02 ` Peter Zijlstra
[not found] ` <20141003210213.GG6324-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-03 21:04 ` Peter Zijlstra
2014-10-03 21:04 ` Peter Zijlstra
2014-10-03 21:04 ` Andy Lutomirski
2014-10-03 21:04 ` Andy Lutomirski
[not found] ` <CALCETrW7OCuAiK31iRvXgXJfcf3FE4GKjpKQ0doWFyUpETzT9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-03 21:12 ` Peter Zijlstra
2014-10-03 21:12 ` Peter Zijlstra
[not found] ` <20141003211204.GQ10583-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-03 21:15 ` Andy Lutomirski
2014-10-03 21:15 ` Andy Lutomirski
2014-10-04 8:13 ` Peter Zijlstra [this message]
2014-10-06 16:44 ` Andy Lutomirski
[not found] ` <CALCETrVvFP66s5XOmSKaC8Vq73=uh11819HOOLkVTu7jJZotew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-03 20:42 ` Peter Zijlstra
2014-10-03 20:42 ` Peter Zijlstra
2014-10-03 20:53 ` Andy Lutomirski
[not found] ` <20141003174141.GR2342@redhat.com>
[not found] ` <20141003174141.GR2342-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-10-03 17:59 ` Andy Lutomirski
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=20141004081324.GR10583@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 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.