LWN: Comments on "Is hyperthreading dangerous?"

mergemem and timing vulnerabilities

anton — Sun, 29 May 2005 11:15:55 +0000

If one could only check whether full pages are merged, that would be
pretty hard to exploit (one would have to guess all of the page
correctly, i.e., usually the complete key or password).

Another potential attack path was using a timing attack based on how
long the merge attempt takes, or how much of the merge-attempted pages
is in the cache afterwards. That would bring the granularity down to
a word or a cache line, which makes guessing much more practical.

IMO, even that attack path could be blocked relatively easily (e.g.,
allow only merging corresponding pages from processes that run the
same binary, and were not tainted with ptrace or somesuch).

My impression was that too much emphasis was given to the
vulnerabilities in the mergemem announcements, and that may be one
reason why there was not much interest in it.

Somewhat OT: Is hyperthreading dangerous?

zakaelri — Fri, 27 May 2005 20:38:37 +0000

Albeit I may pay for it later, this is a great place where TPM (Trusted Computing) could be used. Within the TPM system, the chip responsible for key management is the only one that can ever "see" the keys being used.

Any time a key goes out, it's encrypted. So, you can send in an encrypted key, a datastream, and an encrypt/decrypt/sign/verify instruction... the chip does the magic required, and spits out whichever data was asked for.

Note: While Palladium is evil. I actually like TPM. (My ThinkPad has it, but I havn't had the opportunity to set it up yet).

To make a desparate attempt for on-topic-ness: I disliked HTT from the beginning. It didn't seem worth paying for... It makes more sense (to me) to fine-tune cache performance.

5 to 30% Speed Improvement

MarkWilliamson — Thu, 26 May 2005 13:34:21 +0000

HT doesn't provide extra functional units but it may enable better use of
the functional units available, as well as allowing the CPU to continue
working in the event one thread stalls.

Unfortunately, with cache contention (and the different mix of functional
units required by different threads), the performance benefits can be
highly variable - scheduling-wise it's a whole new can of worms!!!

Dual cores...

MarkWilliamson — Thu, 26 May 2005 13:30:44 +0000

IIRC, the initial dual-cores from AMD and Intel will not share any cache.
Intel's (initial) implementation in particular is basically two
independent CPUs on the same die. Even when shared L2 caches are
implemented, it seems that sharing an L2 cache will provide lower
bandwidth to this kind of exploit, which benefits hugely from the shared
L1 cache of the two hyperthreads.

Note that IBM's POWER4 shares caches across multiple cores and the POWER5
also has SMT...

Threads actually do run simultaneously

MarkWilliamson — Thu, 26 May 2005 13:23:37 +0000

A little quibble about the first paragraph: hyperthreads actually do run
truly simultaneously, which is what distinguishes Simultaneous
MultiThreading from Fine Grained MultiThreading. This gives the
additional benefit of being able to use issue slots in a superscalar CPU
that would otherwise be wasted. Of course, if one stalls, you still get
the benefit that the other thread carries on keeping the processor busy.

Since modern x86 CPUs internally use register renaming and figure out
instruction dependencies dynamically, I've always suspected that adding HT
didn't require many (or perhaps any) changes to the middle part of the
pipeline.

Is hyperthreading dangerous?

mjc@redhat.com — Wed, 25 May 2005 09:53:28 +0000

> In the longer term, authors of cryptographic code may find that they need
> to add avoidance of data-dependent memory access patterns

At least one affected cryptographic library has been evaluating ways to mitigate this issue. OpenSSL is adding contsant-time exponentiation:

http://marc.theaimsgroup.com/?l=openssl-cvs&m=1116207...

5 to 30% Speed Improvement

ksmathers — Fri, 20 May 2005 17:08:41 +0000

If what I've read is correct, hyperthreading increases processor efficiency in the event of a stalled pipeline (such as for a mispredicted branch, or a subroutine entry/exit), but doesn't provide any extra execution units for parallelism. A 30% upper end to speed improvement is about right, but the bottom end is more like -5%. For two CPU bound tasks both of which are contending for cache-lines and each with relatively long spans of instructions between function calls (typically C code instead of C++) Hyperthreading can cause thrashing in the L1 and L2 cache for a net drop in performance.

Is hyperthreading dangerous?

hamjudo — Thu, 19 May 2005 17:35:08 +0000

... is for the cryptography to occur on dedicated processors, designed to make obtaining access to embedded private keys very difficult and expensive.

If the cryptographic keys are mission critical, they must be backed up. The backups also have to be protected, even when stored off site. I think that the most significant benefit of a dedicated processor is that you can have a very different scheme for backing up the crypto hardware than for your other servers.

Is hyperthreading dangerous?

khim — Thu, 19 May 2005 15:13:55 +0000

Does this very theoretical exploit affect multicore systems too?

Yes and no. Yes - it's possible to use the same technique for dual-core systems. But in reality it'll require way too much brute force. The problem with Hyper-Threading is size of L1 cache - it's too small. Multicore systems only share L2 cache (if even that) and it's much bigger so problem becomes pure theory.

Is hyperthreading dangerous?

ballombe — Thu, 19 May 2005 12:56:39 +0000

Interestingly, when the mergemem pacth (http://mergemem.ist.org/) was proposed in 1998, it was accompanied by a note stating a similar security concern. (Hostile programs could generate pages and see whether memory usage go up or not, and deduce they were merged).

Avoidance of data-dependent memory access patterns is already in use in smartcard devices (it is much easier to exploit once you have stolen the smartcard, though).

Is hyperthreading dangerous?

copsewood — Thu, 19 May 2005 12:19:44 +0000

I would question whether it is even possible to make cryptographic computations optimally secure on a highly complex system shared with potentially hostile processes. This kind of attack highlights the kind of difficulties involved. If cryptography is only one of very many things done on a highly complex system, it seems to me unlikely that the security of this cryptography will be done very well. I think a simpler and likely to be more effective approach, once appropriate hardware becomes more generally available, is for the cryptography to occur on dedicated processors, designed to make obtaining access to embedded private keys very difficult and expensive.

Is hyperthreading dangerous?

filipjoelsson — Thu, 19 May 2005 09:42:14 +0000

Does this very theoretical exploit affect multicore systems too? I'm not sure I have this right, but I think they sharing cache too. Or is the (still very theorietical) exploit dependent on the feature that the hostile thread and the cryptographic one do not run at the same time?

In any case, I have the answer:
<TIC>This is the perfect exploit to close with security thorugh obscurity. We have to lessen the risque that the two processes happen to be in the same processor cache at the same time. This is best (depending on wether you share my definition of 'best') done by getting an 8-way SMP system, preferably dualcore. (Well, at least _I_ would prefer that, wouldn't you?) Thus the chance would be slim, at best, that the two processes would schedule to the same processor at the same time. (Now, all I need is to persuade my wife that this is necessary in the name of security.)</TIC>