Re: [patch] Performance Counters for Linux, v4

[Arjan van de Ven <arjan@infradead.org>]

On Tue, 16 Dec 2008 14:03:02 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> > >  - 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.

and/or you use properly implemented crypto code (see Bruce Schneider's
books). The timing "problem" isn't really SMT specific. If you have
improperly implemented crypto (eg crypto code where the code paths and
not just the data payload are key dependent) then on any system with
more than one (logical) processor there is interference that an
attacker can use.

The only possible answer is to use proper implementation; turning off HT
may make you feel good but you go from shoddy crypto for which there is
some internet papers on how to crack it, to shoddy crypto for which the
same papers apply ;)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org