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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
