K
keith
Ok, you got me. What weakness in DES does that expose? A potential
security weakness, sure.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Ok, you got me. What weakness in DES does that expose? A potential
security weakness, sure.
S
Stephen Fuld
Colin Andrew Percival said:And, predictably, they completely missed the point.
A good idea, but irrelevant to this attack.
A good idea, but fails to recognize that my attack can also obtain
information from non-cryptographic processes which use non-oblivious
algorithms. Cryptography is a big target, but certainly not the only
one.
Completely irrelevant. Dual-core processors are no more affected by this
than single-core processors, and far less than hyperthreaded processors.
While I agree with the general tenor of your post, ISTM that a dual core
processor that shares cache at some level (some existing designs do), is as
vulnerable as a hyperthreaded processor. To be precise, you should talk
about a vulnerability where multiple processes/cores simultaneously share
caches, not specifically of hyperthreading.
Y
Yousuf Khan
Colin said:Completely irrelevant. Dual-core processors are no more affected by this
than single-core processors, and far less than hyperthreaded processors.
What's that Gartner said about Intel being able to demonstrate this
attack even on single-threaded processors? It seems nearly impossible to
do this with only one thread running at a time.
Yousuf Khan
T
Tom Linden
Can the cache be shared by separate processes?What's that Gartner said about Intel being able to demonstrate this
attack even on single-threaded processors? It seems nearly impossible to
do this with only one thread running at a time.
A
Anne & Lynn Wheeler
Tom Linden said:Can the cache be shared by separate processes?
ugh ... nearly 40 years ago as an undergraudate
.. .. i started doing a bunch of work on page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
on multi-user timesharing systems
http://www.garlic.com/~lynn/subtopic.html#timeshare
that was being turned around and shipped in commercial systems,
actually, i was also doing the generalized resource scheduling
algorithms that also were being shipped in commercial systems
http://www.garlic.com/~lynn/subtopic.html#fairshare
.... anyway ... I was asked several times about the problem of
low-bandidth information leakage and what was I going to do about it.
C
Colin Andrew Percival
In comp.arch Yousuf Khan said:What's that Gartner said about Intel being able to demonstrate this
attack even on single-threaded processors?
I don't know exactly -- Intel hasn't been willing to talk to me about
that.
It seems nearly impossible to
do this with only one thread running at a time.
If you can provoke lots and lots of context switches, it might be
possible to steal a key by taking advantage of information leakage
across context switches. As I discuss in my paper, this provides
a very easy covert channel, but it is not clear if it can actually
be used to steal keys.
Colin Percival
Y
YKhan
Colin said:If you can provoke lots and lots of context switches, it might be
possible to steal a key by taking advantage of information leakage
across context switches. As I discuss in my paper, this provides
a very easy covert channel, but it is not clear if it can actually
be used to steal keys.
Now, one thing that puzzles me is how does a thread read directly from
a cache? My assumption was that the cache was transparent to the
software. All a software can do is generate a memory address, which is
then redirected through the cache; but it can't ask for as specific
location inside the cache. The processor cache maintains hash tables to
prevent similar-looking memory addresses from being sent to the wrong
thread.
Yousuf Khan
Y
YKhan
Colonel said:Well, then, what do you think about simply splitting the cache
among cores? It really depends on how workload gets allocated.
If each core ends up with a roughly equivalent working set of
cached storage, why bother with an elaborate protection scheme
when you can just split and firewall it?
I believe that that is basically what the majority case in dual-core
technology already is. All cores have their own private cache.
Yousuf Khan
T
Tom Linden
Precisely, and what did you do about it? Nothing, because the bandwidthugh ... nearly 40 years ago as an undergraudate
. .. i started doing a bunch of work on page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
on multi-user timesharing systems
http://www.garlic.com/~lynn/subtopic.html#timeshare
that was being turned around and shipped in commercial systems,
actually, i was also doing the generalized resource scheduling
algorithms that also were being shipped in commercial systems
http://www.garlic.com/~lynn/subtopic.html#fairshare
... anyway ... I was asked several times about the problem of
low-bandidth information leakage and what was I going to do about it.
was too low, but now with the speed available today the bandwidth of covert
timing channels is 'usable'
K
keith
Now, one thing that puzzles me is how does a thread read directly from
a cache? My assumption was that the cache was transparent to the
software. All a software can do is generate a memory address, which is
then redirected through the cache; but it can't ask for as specific
location inside the cache. The processor cache maintains hash tables to
prevent similar-looking memory addresses from being sent to the wrong
thread.
AFAICT, the issue is in inter-process communication though timing of
cache transactions. One can signal across processes by accessing cache
lines, thus causing a change in memory latency to the other process. If
one process is known (RSA) one can measure its usage of the cache, even
though you may not have "system" priveleges. It's not the cache itself
leaking, rather that timing information is available.
OTOH, I could be all wet. ;-)