6 ms·
Hyper-Threading has been a source of security concerns for a decade now, and vulnerabilities in existing HT implementations have been trickling out over the las
by StudentStuff 7y ago
Hyper-Threading has been a source of security concerns for a decade now, and vulnerabilities in existing HT implementations have been trickling out over the last few years. Unlike Management Engine or TrustZone, at least we can disable Hyper-Threading (for a 30% performance hit).
- rightbyte 7y agoThe security concern is remote code execution via JS, and sharing processor time with other people you don't trust, right? It should be up to the VM-as-a-service and browser vendors to flush the cache properly.
- compiler-guy 7y agoNo. The security concern is attackers reading data they shouldn’t. The article explains how. “Microarchitectural Data Sampling (MDS) is a group of vulnerabilities that allow an attacker to potentially read sensitive data.” That is way more serious than stealing cycles.
- silversconfused 7y agoOne CPU per process makes a lot more sense, especially now that we have so many specialized CPUs in our machines anyway.
- rightbyte 7y agoYe I got a feeling that shared processor time with strangers is not viable without specialized hardware.
- snovv_crash 7y agoI think it isn't viable with non-deterministic (in time) hardware behavior. This means dedicated caches, or no caches at all. Dedicated guaranteed memory speeds and latencies. Dedicated processing units. The untrusted code cannot be affected by other code, otherwise the other code leaks its usage patterns across.
- bloomer 7y agoFrom a brief read, I think it reads in flight data not necessarily cached, so flushing cache won't help unfortunately.
- smnra 7y ago30% performance hit? I'm sure that heavily depends on the workload... and I'm also sure you lose performance when HT is on, depending on the workload as well.
- silversconfused 7y agoI've seen this claim made for routers and other low intensity low latency workloads.
- penagwin 7y agoThat would make sense, my understanding is that with a 100% pegged CPU hyperthreading won't be super beneficial as they aren't real cores, just smarter scheduling. You can't really schedule 100% load better, however for applications that are latency specific it would make more sense, as you don't have the CPU pegged, you just want a faster response.
- api 7y ago> You can't really schedule 100% load better Sure you can. You can do math while another HT is waiting for memory. Sometimes you can even multiplex use of multiple ALUs or one HT can do integer and another can do floating point. It's actually under high multithreaded load that HT shines, especially if that load is heterogenous or memory latency bound.
- astrange 7y agoWouldn't hyperthreading also be more power-efficient compared to running a second core?
- ajdlinux 7y agoI too was once under the misapprehension that HT was "just smarter scheduling", until I took a university course in microarchitecture that explained how Simultaneous Multithreading actually works in terms of maximising utilisation of various types of execution units. I wonder why "smarter scheduling" became a common understanding.
- beagle3 7y agoAlso, HT is not such a great performance win - on a few different 4-core/8-thread machines, I had access to, loading all 8 threads to "100% CPU" (whatever that means) usually only delivers 20-30% faster computation than with HT off (4-core/4-thread) - which is inline with your 30% number. And that's an improvement - some 15 years ago, with similar computational loads, most of my tests ran 10-20% faster with the HT off (using 2 core / 2 threads) than with HT on (using 2 core / 4 threads) - there just wasn't enough cache to support those many threads.
- ajross 7y agoA 20-30% increase is a BIG increase for a hardware feature, though. The cost of hyperthreading in transistors mostly amounts to the larger total register set. The whole point is the rest of the decode/dispatch/execute/retire pipeline is all shared.
- kccqzy 7y agoHow is 20%-30% not a great performance win? If I tell you today there's this One Simple Trick that you can do on your computer to instantly gain access to 20%-30% more performance, would you do it in a heartbeat?
- pertymcpert 7y agoWhat do you think is a good performance improvement then?
- beagle3 7y ago(and to the two other responses) If your workload is already well parallelized, then, yes 20% is quite significant. However, working to parallelize properly over 8 rather than 4 has its own costs. The thing that bothers me most is that 800% CPU and 500% CPU on this processor are roughly equivalent at 5x100%CPU, it makes everything very hard to reason about when planning capacity.
- pertymcpert 7y agoI think you’re misunderstanding what HT is. It’s not true parallelism, it’s just hiding latency by providing some extra superscalar parallelism. You can’t expect it to give you actual linear improvements in performance because it’s just an illusion.
- jandrewrogers 7y agoDisabling hyper-threading is highly unlikely to produce a 30% performance hit. Most highly optimized software disables or avoids hyper-threading because doing so increases performance. Hyper-threading tends to benefit the performance of applications that have not been optimized, and therefore presumably are also not particularly performance sensitive in any case.
- jcelerier 7y agoIn music production and C++ code compilation I get a pretty reliable +25% perf boost with HT on (this was not the case a few gens ago though).
- berkut 7y agoIn highly-parallel workloads like rendering (ray tracing) where pipeline stalls due to loads happen quite regularly, it's fairly easy to get 20-35% speedups with HT.
- ivl 7y agoDecade and a half, even. If I remember right, the first CVE for an HT security flaw was summer 2005.
- cperciva 7y agoI announced it publicly 14 years ago yesterday.
- mmastrac 7y agoThis one? https://nvd.nist.gov/vuln/detail/CVE-2005-0109 https://nvd.nist.gov/vuln/detail/CVE-2005-0109 Dang: "Hyper-Threading technology, as used in FreeBSD and other operating systems that are run on Intel Pentium and other processors, allows local users to use a malicious thread to create covert channels, monitor the execution of other threads, and obtain sensitive information such as cryptographic keys, via a timing attack on memory cache misses." Also, found elsewhere: "According to Linus Torvalds and others on linux-kernel this is a theoretical attack, paranoid people should disable hyper threading"
- cperciva 7y agoYes. Intel dismissed it at the time, saying that "nobody would ever have untrusted code running on the same hardware on which cryptographic operations are performed".