Re: Tightening up rdpmc permissions?
From: Andy Lutomirski
Date: Wed Oct 08 2014 - 19:47:58 EST
On Mon, Sep 29, 2014 at 11:42 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Sep 29, 2014 10:36 AM, <Valdis.Kletnieks@xxxxxx> 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...)
I have a prototype patch that seems to work and should have relatively
little overhead. I'll send it either when the merge window closes or
when some pending dependencies get resolved.
AMA Capital Management, LLC
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/