13 ms·
OpenBSD disables Intel's hyperthreading due to security concerns
- Someone1234 8y agoOuch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
- moab 8y agoIt's still important to hide latency and saturate the memory controllers for programs with irregular memory accesses (e.g. graph algorithms), although the difference is not 2x, but something more like 10-15% over running without hyper-threading.
- derekp7 8y agoOn the other side, a hyperthreaded CPU used to be about 10 - 30% gain, but in tests I've ran on recent hardware (HP DL380 Gen 10) hyperthreading gives around 70% more performance (the test I used was running pigz [parallel gzip] on a large file).
- greglindahl 8y agoThat's a great example of how hyperthreading's performance effects are extremely workload dependent.
- hermitdev 8y agoExcept the performance of hyper-threading today is far better than it was first introduced. I had a dual-socket P4 Xeon box w/ HT around 2003. Single-threaded performance with HT enabled was around 70% of what it was with HT disabled. Today, I think you'd see only about 95-98% of enabled vs disabled performance. I don't have hard numbers to back this up, it's purely my personal experience/recollection. On my 2 socket P4 Xeon box, I disabled HT. On my current I7 6-core box, I have HT on.
- garganzol 8y agoDepends on load. I run parallel integration tests on hyper-threaded machines and usually see 80% gains.
- classichasclass 8y agoThe implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.
- mrpippy 8y agoI think the only other OpenBSD architecture that supports any SMT chips is sparc64 (like the US T1/T2). Unless an actual vulnerability is found, I don't see other OSes following this lead
- aade 8y agoWhy not? It’s arguably a way to make it slightly safer to run on Intel.
- temprature 8y agoAn "actual vulnerability" has been found. It's amazing that even after the lazy FPU fiasco, people think OpenBSD did this on a complete whim.
- mrpippy 8y agoI stand corrected. From the commit message this seemed much more speculative than the FPU vulnerability (where Theo admitted to being tipped off by someone under the embargo), but clearly it's more than just speculation. https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-when-protecting-your-cpu-caches-is-not-enough-10149 https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-w...
- andreiw 8y agoAlso 64-bit Arm...
- joesavage 8y agoAs far as I’m aware SMT in Arm cores is pretty uncommon actually.
- jimrandomh 8y ago> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for performance.
- classichasclass 8y agoI'm not sure that would necessarily fix the problem definitively. Say you had a browser running web-exposed JavaScript on a thread. You could still finagle a Spectre-type information leak that way by having the JavaScript thread snoop other browser threads, assuming no other mitigations.
- endianswap 8y agoDon't most browsers run one process per page/tab nowadays?
- greglindahl 8y agoChrome does, Firefox does not (I've got 5 processes for a billion tabs.)
- valarauca1 8y agoFirefox process per tab is behind a feature flag as it’s in testing still
- timvisee 8y agoI don't think the plan is to ever enable this in the comming few years. The current approach with a few tabs is much more memory efficient, which is why they've chosen it.
- DSingularity 8y agoOuch. Huge hit for performance.
- Forbo 8y agoFrom the commit message, it sounds like that might not necessarily be the case: "Note that SMT doesn't necessarily have a posive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores."
- AHTERIX5000 8y agoWonder why, because of poor SMP scalability and coarse locking? I've encountered some cases where SMT made performance worse such as with very optimized HPC libs but in general SMT can really help. Compiling projects got a nice boost when enabling HT on Intel's recent arch for example (all of this on Linux though, last time I checked OpenBSD its SMP perf was abysmal)
- Uberphallus 8y agoFor I/O and memory bound processes, it makes it worse, saturating further buses that are already saturated. For regular. For CPU bound, it may help or not, depending on many factors, like cache/memory contention, nature of the operations... Compilation can get boosts because while some threads are waiting for I/O others are crunching source files. Also the variety of computation is high enough so multiple threads don't overlap too much on functional unit usage. If you try to build from a filesystem in memory, you'll find way a less impressive speedup (if any).
- AHTERIX5000 8y agoYeah I've spent my time looking at perf counters and I'm aware how cache access patterns affect. But the statement was drastic enough to make me suspect there is something more OpenBSD specific going on.
- 8y ago
- nbyouri 8y agoOpenBSD finds yet another way to shoot themselves in the foot.
- Forbo 8y agoI'd say it's probably closer to: > OpenBSD finds yet another way to harden their OS. This is a conscious choice to disable something that could potentially allow for an entire class of security vulnerabilities. I suppose a decent analogy could be they chose to amputate a damaged foot before it had time to turn gangrenous.
- nbsd4life 8y agoYes, it's probably easier to exploit with hyperthreading, but does disabling hyperthreading stop the exploits? No, it's just an incomplete solution and a minor setback at an enormous cost. OpenBSD does these often, and it looks silly doing it.
- antoinealb 8y agoEnormous cost? If you want to re-enable hyperthreading its just a sysctl away. I mean, OpenBSD is something you are expected to tweak anyway.
- notsofastbuddy 8y agoBy continuing a security-first mindset that they've been establishing for decades?
- deleted 8y ago[deleted]
- zeth___ 8y agoThe most secure computer is a toaster. The only way to minimize attacks is to have less capable language classes exposed to the outside world. The last time I checked they still have an http stack which is usually either turing complete or context sensitive.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- keldaris 8y agoSo... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations and improving their scheduler is hard, so they'll pre-emptively disable HT outright on Intel CPUs now and others in the near future? I'm not an OpenBSD user (and glad for it, if this is anything to go by), but I'm curious - is this really how they operate, or does this decision stand out?
- zokier 8y agoYeah, they are fairly risk-averse and not really performance oriented, so this decision feels pretty much in line with their practice.
- 2trill2spill 8y ago> I'm not an OpenBSD user (and glad for it, if this is anything to go by), but I'm curious - is this really how they operate, or does this decision stand out? I'm not a OpenBSD user either, I use FreeBSD whenever possible. However from listening to OpenBSD devs, via blogs, conferences, HN, etc, it seems that OpenBSD is an operating system built mainly for OpenBSD developers, their goals support this[1]. OpenBSD being useful for non OpenBSD developers is more of a secondary goal compared to how FreeBSD or Linux or any other OS handles it. Also OpenBSD is much more of a research operating system then other large successful OS(Linux, Windows, MacOS, FreeBSD, etc). Meaning OpenBSD cares way more about developing features and novel security mitigations then trying to maintain backwards compatibility like other operating systems do. > So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations and improving their scheduler is hard, so they'll pre-emptively disable HT outright on Intel CPUs now and others in the near future? The OpenBSD devs strongly suspected another Intel hardware bug a week or two ago, implemented a mitigation and deployed it. Turns out they were right[2]. [1]: https://www.openbsd.org/goals.html https://www.openbsd.org/goals.html [2]: https://www.bleepingcomputer.com/news/security/new-lazy-fp-state-restore-vulnerability-affects-all-intel-core-cpus/ https://www.bleepingcomputer.com/news/security/new-lazy-fp-s...
- da_chicken 8y ago
- mehrdadn 8y agoDo you get the exact same performance characteristics by ignoring the extra virtual cores as you would have gotten if you could actually disable hyperthreading in the CPU via the firmware setup? Or does it result in some CPU resources becoming unusable that would otherwise be usable if HT were truly disabled?
- notaplumber 8y agoOperating systems can't disable HT/SMT in the same way as the BIOS/firmware can, but presumably it will be fine if the kernel only schedules the idle process on HT "cores", it will spend much of, or all its time in a lower power state (MWAIT? C-states?), presumably the CPU is smart enough to handle that.
- mehrdadn 8y agoI guess figuring out whether it's only "presumably" or actually "actually" was why I asked the question in the first place.
- notaplumber 8y agoHmm. This thread on the OpenBSD lists suggests it may be adequate, of course disabling in the BIOS is certainly a better option, if you can. https://marc.info/?t=152938773300027&r=1&w=2 https://marc.info/?t=152938773300027&r=1&w=2
- blattimwind 8y agoAt least in previous generations some resources where statically shared, but most were dynamically shared.
- kojon99 8y agoThey should make it easier to find the diff behind all openbsd emails. I can’t find this one.
- foodstances 8y agohttps://github.com/openbsd/src/commit/96c11352863a7f6240b4e5e388052f414b75f95b https://github.com/openbsd/src/commit/96c11352863a7f6240b4e5...
- petee 8y agoAlthough not ideal, and there is likely an easier way to do it in full CVS (but i lack those skills), but you can always go to their Web CVS and manually check the files listed in the commit: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/cpu.c.diff?r1=1.122&r2=1.123&f=h https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64...
- gerdesj 8y agoFFS: so far I've seen shit loads of "oooo - stuff <wave hands>" here from people who are clearly not experts or even understand the issues properly in this. Neither am I. OP (and environs) has names on it that I have seen before and respect as knowing what the hell they are on about.
- deleted 8y ago[deleted]
- Scramblejams 8y agoI've never trusted hyperthreading for workloads I haven't tested. Sometimes it's faster, often it's slower. Beyond that, I've been suspicious of its security implications from day one. My first trip through the BIOS on a personal machine always includes turning it off.
- rythie 8y agoYou could just buy i5 based machines instead which don't have hyperthreading.
- deleted 8y ago[deleted]
- krylon 8y agoFrom what I have seen, I think many dual-core i5 CPUs for notebooks support hyperthreading.
- letsgetphysITal 8y agoThe U (ultra-low power) lines are indeed two-core with Hyperthreading. All others are 4 core without.
- krylon 8y agoOkay, that explains it. The only i5-based systems I have used (or still use) are notebooks.
- berbec 8y agoThis changed with 8th-gen Intel. The low-powers are now dual-HT/quad/quad-HT i3/i5/i7 [1]/[2]/[3] 1: https://ark.intel.com/products/137977/Intel-Core-i3-8130U-Processor-4M-Cache-up-to-3_40-GHz https://ark.intel.com/products/137977/Intel-Core-i3-8130U-Pr... 2: https://ark.intel.com/products/124969/Intel-Core-i5-8350U-Processor-6M-Cache-up-to-3_60-GHz https://ark.intel.com/products/124969/Intel-Core-i5-8350U-Pr... 3: https://ark.intel.com/products/122589/Intel-Core-i7-8550U-Processor-8M-Cache-up-to-4_00-GHz https://ark.intel.com/products/122589/Intel-Core-i7-8550U-Pr...
- deleted 8y ago[deleted]
- epynonymous 8y agoi didnt see this posed in the comments, but it was certainly tops on my mind. is this the same issue for linux kernel?
- petee 8y agoIf they are using Hyper Threading, then yes, unless they already have a different architecture: "We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial."
- aade 8y agoThe (recent) SPARC Hypervisor does a fair job at this. Fujitsu has an interesting implementation. But it would be conceivably difficult to do this with time sharing on Intel chips without exposing side channels. That kind of control should be supervisory and in control of the chip. I haven’t yet seen that on Intel, but I’ve heard there are some hardware manufacturers that are looking to do something like that.
- creo 8y agoWhat scares me is that they do OS wide change based of wording "This can make", "And since we suspect" and "In all likelyhood" instead of doing actual tests. I know that open systems doesn't have required workforce, but doing changes based on subjective reasoning is slippery slope.
- monort 8y agoIf it's a response to LazyFP bug, then it's under embargo, you can't have a test yet.
- detaro 8y agoDid it scare you when your operating system started to support it, on the basis that it would "in all likelyhood" be fine? For a system aiming at security, it's a completely valid choice to disable things that start to look questionable, even if it's not conclusively proven yet. Just like potential software vulnerabilities are patched even if nobody has demonstrated that they actually are exploitable yet.
- flurrything 8y agoThey care about making OpenBSD secure, not about producing security exploits. Many OpenBSD devs are security researchers in academia. If they hear whisphers over beers that there are new Spectre attacks coming that exploit this or that, they might not be able to reproduce the exploit without putting a lot of work into it (it's research after all), but they might be able to prevent it by making a simple change, like disabling hyperthreading. OpenBSD cares more about security than basically any other trade-off in OS design (performance, usability, ...), so it makes sense to me that they went this way. If you want a balance of security and performance, OpenBSD is not for you any ways.
- equalunique 8y agoI was going to submit this news from the source I learned it from, which has the novel peculiarity of coming from a site that's name is similar to this one: https://thehackernews.com/thn/2018/06/openbsd-hyper-threading.html https://thehackernews.com/thn/2018/06/openbsd-hyper-threadin...
- GrayShade 8y agoThere are some Linux HT benchmarks here: https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1 https://www.phoronix.com/scan.php?page=article&item=intel-ht...
- lightedman 8y agoQuick question. In theory, wouldn't these same attacks on logical cores also apply to systems with multiple physical cores or multiple CPU sockets? If so, what's the point of disabling hyperthreading? If this holds true, wouldn't the real answer be to disable all cores but one?
- tynecomputers 8y agoDoes anyone know when they are going to patch this or is it a permanent fix?
- 64656656 8y agoi found this two blogs http://mawazo.tk#---- http://mawazo.tk#---- and hettp//cnn.com