On Sat, Nov 1, 2014 at 3:10 PM, Thomas Gleixner <[email protected]> wrote: > On Sat, 1 Nov 2014, Andy Lutomirski wrote: >> On Nov 1, 2014 1:39 PM, "Thomas Gleixner" <[email protected]> wrote: >> > On Sat, 1 Nov 2014, Andy Lutomirski wrote: >> > > There's plenty of room to tighten up the restrictions further, but >> > > this is, I think, a decent first step, and it solves the problem of >> > > information leaking into seccomp sandboxes. >> > >> > In which way? >> >> All the performance counters were readable without using any syscalls. >> That leaks hints as to which events are in use, and it possibly leaks >> interesting side channel information. With this series applied, you >> need a at least mmap an rdpmc-able event, which most seccomp sandboxes >> won't allow. > > Ok. So you are preventing the seccomp sandboxes to open/mmap a counter. >
Yes. Conversely, if someone lets perf_event_open through a seccomp filter, then the sandboxed code can probably gather more interesting information using perf_event_open the normal way than they can by poking at rdpmc. --Andy >> Unfortunately, rdpmc access to counters can't be controlled >> individually, so it's hard to do all that much better than this. > > Yeah, I know ... > > Thanks, > > tglx -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
