Messages in this thread | | | Date | Sun, 15 May 2005 11:31:17 +0200 | From | Adrian Bunk <> | Subject | Re: Hyper-Threading Vulnerability |
| |
On Fri, May 13, 2005 at 12:02:44PM -0700, Andy Isaacson wrote: > On Fri, May 13, 2005 at 11:30:27AM -0700, Vadim Lobanov wrote: > > On Fri, 13 May 2005, Andy Isaacson wrote: > > > It's a side channel timing attack on data-dependent computation through > > > the L1 and L2 caches. Nice work. In-the-wild exploitation is > > > difficult, though; your timing gets screwed up if you get scheduled away > > > from your victim, and you don't even know, because you can't tell where > > > you were scheduled, so on any reasonably busy multiuser system it's not > > > clear that the attack is practical. > > > > Wouldn't scheduling appear as a rather big time delta (in measuring the > > cache access times), so you would know to disregard that data point? > > > > (Just wondering... :-) ) > > Good question. Yes, you can probably filter the data. The question is, > how hard is it to set up the conditions to acquire the data? You have > to be scheduled on the same core as the target process (sibling > threads). And you don't know when the target is going to be scheduled, > and on a real-world system, there are other threads competing for > scheduling; if it's SMP (2 core, 4 thread) with perfect 100% utilization > then you've only got a 33% chance of being scheduled on the right > thread, and it gets worse if the machine is idle since the kernel should > schedule you and the OpenSSL process on different cores... >...
But if you start 3 processes in the idle case you might get a 100% chance?
> -andy
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |