Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD disables Intel's hyperthreading due to security concerns

mail-archive.com

Post reply on HN
Print view View original

111–120 of 158 posts

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#111

Post by gargravarr »

orf wrote: post #108
flurrything wrote: post #103

Earlier quoted context omitted.

> is this really how they operate, OpenBSD is a research operating system and security is a core component of their research. Pro-actively mitigating security risks before exploits appear is one way to improve security that has worked in the past: vulnerabilities having been fixed before they appeared. Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop…

> Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop by hardware vendors like Intel who requested 1 year to fix meltdown. Is 90 days really a reasonable timeframe to fix something like meltdown? I agree with your whole comment in general, but hardware/microcode issues at Intel's scale are a different beast than some buffer overflow.

Not to forget, Intel have said this collection of exploits cannot be fixed in microcode, only mitigated - it's so fundamental to the CPU hardware that it requires redesigning the chip to fix properly. The mitigation has led to serious performance hits and further problems down the line. And the permanent fix requires eventually replacing the CPU.

As has been previously noted, Meltdown, Spectre and related exploits came about because nobody ever thought it would be possible to access the cache from other processes. 1 year is probably quite reasonable for Intel to redesign the architecture (in fact, is probably going to stretch to 2 years or more), but people need security fixes now. In this case, it looks like OpenBSD are taking the right approach.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#112

Post by krylon »

rythie wrote: post #95
Scramblejams wrote: post #46

I'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.

You could just buy i5 based machines instead which don't have hyperthreading.

From what I have seen, I think many dual-core i5 CPUs for notebooks support hyperthreading.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#113

Post by rbanffy »

kbenson wrote: post #64
greglindahl wrote: post #63

Earlier quoted context omitted.

It's becoming popular to want to push machine learning tasks onto edge devices like mobile and desktop CPUs, for example apps that include some machine learning. Some of these machine learning algorithms do a lot of matrix multiplies. "Typical" is highly varied, and it changes. Edit: here's an example: Google brings on-device machine learning to mobile with TensorFlow Lite https://thenextweb.com/artificial-intelligen…

Would they be using mostly CPU for that, or would they offload it to the GPU or a dedicated chip? I would assume you would use your general purpose CPU only if all else wasn't available (and generally there's a GPU available on most end user devices these days).

Running the model is much easier than training it. On power-constrained environments, DSPs can do it.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#114

Post by AHTERIX5000 »

Forbo wrote: post #14
DSingularity wrote: post #11

Ouch. Huge hit for performance.

From 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."

Wonder 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)

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#115

Post by bigato »

2trill2spill wrote: post #39
keldaris wrote: post #19

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? 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…

> 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…

> 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.

This is not the feeling I get from OpenBSD at all. They don't act like research. They aren't keen on implementing new features just for the sake of it, or just to try it out. A better description would be that they put correctness, security and maintainability first, and simplicity often comes as a nice side effect. Deprecating old, unused features is just a consequence of striving to decrease complexity by trimming your code base. OpenBSD is one of the few OS where the number of lines of code is not skyrocketing to unmanageable numbers.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#116

Post by petee »

epynonymous wrote: post #91

i didnt see this posed in the comments, but it was certainly tops on my mind. is this the same issue for linux kernel?

If 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."

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#117

Post by keldaris »

flurrything wrote: post #103
keldaris wrote: post #19

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? 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…

> is this really how they operate, OpenBSD is a research operating system and security is a core component of their research. Pro-actively mitigating security risks before exploits appear is one way to improve security that has worked in the past: vulnerabilities having been fixed before they appeared. Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop…

> if an OS is as security conscious as OpenBSD, there isn't really a different way to operate

That's really what I was getting at with my question. There's no such thing as absolute security, it is a set of tradeoffs between usability, performance and specific security guarantees. Is there a point where the OpenBSD developers would say "okay, this is a (potential or confirmed) security bug, but the mitigation is just too costly in this case"?

In the post-Spectre world, it's not completely inconceivable to contemplate the possibility that, in order to retain the security guarantees most people thought they had, one might have to give up a substantial subset of the benefits of speculative execution in out of order processors. For some workloads that might mean up to two orders of magnitude in performance. I know roughly where the common operating systems would draw the line and I certainly know where I would, for my own usecases. I'm just curious about how OpenBSD works in this regard.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#118

Post by Tepix »

classichasclass wrote: post #6
jimrandomh wrote: post #4

> 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 perf…

I'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.

Once operating systems offered this mitigation mechanism, I'm sure browser vendors would use them.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#119

Post by aade »

mrpippy wrote: post #35
classichasclass wrote: post #3

The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.

I 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

Why not? It’s arguably a way to make it slightly safer to run on Intel.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#120

Post by letsgetphysITal »

krylon wrote: post #112
rythie wrote: post #95

Earlier quoted context omitted.

You could just buy i5 based machines instead which don't have hyperthreading.

From what I have seen, I think many dual-core i5 CPUs for notebooks support hyperthreading.

The U (ultra-low power) lines are indeed two-core with Hyperthreading. All others are 4 core without.
Post reply on HN