On Sep 29, 2014 10:36 AM, <[email protected]> wrote: > > On Mon, 29 Sep 2014 09:39:16 -0700, Andy Lutomirski said: > > > Would it make sense to restrict rdpmc to tasks that are in mms that > > have a perf_event mapping? After all, unless I misunderstand > > something, user code can't reliably use rdpmc unless they've mapped a > > perf_event object to check the rdpmc bit and figure out what ecx value > > to use. > > Wouldn't that be trivially easy for an attacker to bypass? Just map a dummy > perf_event object and then go to town?
Depends on the paranoia setting. We could require that the mapped object actually have an rdpmc-able counter running. Seccomp can (and often does) block access to perf_event_open entirely. We could certainly change the code to only twiddle CR4 if TIF_SECCOMP or TIF_NOTSC is set. I think that the real thing we should optimize for is to minimize the chance that a given context switch actually needs to *change* cr4. Since perf_event maps are relatively unusual, at least only perf-using programs would have overhead if we just gated it on the existence of a useful rdpmc-able mapping. (Also, why on earth is TIF_NOTSC a thread_info flag? Wouldn't just adding a field "cr4" to task_struct or something be simpler and quite possibly faster? We have a branch anyway...) --Andy -- 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/
