Re: [patch] Performance Counters for Linux, v4

[Ingo Molnar]

* Pavel Machek <pavel@xxxxxxx> wrote:

> On Tue 2008-12-16 13:50:00, Ingo Molnar wrote:
> > 
> > * Pavel Machek <pavel@xxxxxxx> wrote:
> > 
> > > Hmm, if I timec some setuid program, what happens?
> > 
> > yes, i already had a quick look at that a few days ago when i implemented 
> > counter inheritance (for different reasons) and couldnt find the cleanest 
> > place to put the exec() flushing into so i procrastinated that a bit :)
> > 
> > > Performance counters seem like great tool to pull secret keys out of 
> > > other processes :-).
> > 
> > if you worry about _that_ angle you also have to:
> > 
> >  - turn off the cycle counter
> > 
> >  - turn off precise utimes
> 
> Probably good idea, yes.
> 
> >  - plus you have to forbid SMT CPUs as well. On HT a task could
> >    co-schedule with your setuid task and observe its timing
> >    characteristics via its _own_ behavior. (which is impacted by whatever
> >    is running on another SMT/HT thread.)
> 
> Yes, SMT is evil.

HT got added back to Nehalem, so SMT is coming to you in every future x86 
CPU. It brings a serious performance win, so nobody will turn off SMT 
threading in practice. If SMT worries you, it needs explicit partitioning 
of security-relevant processing to different physical CPUs, via 
cgroups/cpusets/etc.

> > the real exec() worry are: active, IRQ driven samples/events. Not possible 
> > yet via the current iteration of counter inheritance (hence my 
> > procrastination) - but it makes sense and that's why i was looking at the 
> > exec() angle.
> > 
> > and that will flush simple counters too, removing your theoretical attack 
> > angle as well.
> > 
> > So how about the patch below?
> 
> Thanks!
> 
> > Subject: perfcounters: flush on setuid exec
> > From: Ingo Molnar <mingo@xxxxxxx>
> > Date: Tue Dec 16 13:40:44 CET 2008
> > 
> > Pavel Machek pointed out that performance counters should be flushed
> > when crossing protection domains on setuid execution.
> > 
> > Reported-by: Pavel Machek <pavel@xxxxxxx>
> > Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> 
> Acked-by: Pavel Machek <pavel@xxxxxxx>

find below the final commit, thanks Pavel.

	Ingo

------------>