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

141–150 of 158 posts

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

#141

Post by _chris_ »

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…

> So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations

Spectre is about a) leaving side-effects of misspeculation in shared resources, and b) bandwidth contention (between a misspeculated instruction stream and an attacker) to shared resources.

It is trivially obvious that HT exacerbates Spectre-class bugs, as the entire raison d'être to HT is to share pipeline resources. How quickly information can be leaked can be up for debate, but it's definitely non-zero.

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

#142

Post by keldaris »

bigato wrote: post #140
keldaris wrote: post #138

Earlier quoted context omitted.

There's no backpedaling, I still think their approach is crazy for any practical usecase I care about. Beyond that, I simply expressed curiosity to learn more about the extent of the tradeoffs they're willing to make.

They don't set defaults for the average use case when security is involved. This is the difference between: "Secure by default", turn knobs if you need more speed "Fast by default", turn knobs if you need more security Not that the knobs will be always available for each design decision, but sometimes they are there and you can turn them at your own risk. It probably would be wise to understand the consequences. Some…

> They don't set defaults for the average use case when security is involved.

They certainly set the defaults for some usecase, it just happens to be more security-biased than most. They don't ship an OS for an airgapped toaster, so it can't ever literally be "secure by default", it's just a compromise on the tradeoff scale that's more security-oriented than most. It still needs to be usable (for some set of people) and it still has to achieve some baseline level of performance to be usable - I was trying to get some clarity on the latter.

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

#143

Post by lightedman »

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

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

#144

Post by gnufx »

ailideex wrote: post #102
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.

Can you give example of where it was slower for you with HT enabled?

HPC workloads normally at least won't benefit and probably take a hit from HT on Xeon-ish hardware at least. It's normally turned off on HPC compute nodes (perhaps in software so the resource manager can enable per-job if necessary). There are exceptions, particularly with KNC and, perhaps, KNL. The situation is likely different for POWER, but I don't have experience of it.

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

#145

Post by berbec »

krylon wrote: post #132
letsgetphysITal wrote: post #120

Earlier quoted context omitted.

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

Okay, that explains it. The only i5-based systems I have used (or still use) are notebooks.

This 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-Pr... 2: https://ark.intel.com/products/124969/Intel-Core-i5-8350U-Pr... 3: https://ark.intel.com/products/122589/Intel-Core-i7-8550U-Pr...

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

#146

Post by chasil »

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…

Perhaps it makes more sense to require that all processes on an individual core share the same UID.

Browsers are particularly problematic, and it would be nice to alert the scheduler that a particular process is untrusted and extra care should be taken to sanitize caches before and after its time slice.

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

#147

Post by chasil »

temprature wrote: post #128
keldaris wrote: post #117

Earlier quoted context omitted.

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

It's a sysctl that can be toggled. If you want hyperthreading and don't care about the security concerns, you can turn it back on. The commit message specifically mentions that this was implemented because many modern machines don't allow hyperthreading to be disabled in the BIOS. You'll find out in a couple of months why they did this. I hope you'll remember the comments you've written when that happens, because you…

There is a thread at lobste.rs that demonstrates the setting, immediately idling half of the CPUs presented in top:

https://lobste.rs/s/ifr52b/openbsd_disables_intel_s_hyperthr...

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

#148

Post by smaddox »

adrianN wrote: post #92
greglindahl wrote: post #52

Earlier quoted context omitted.

Typical workloads? What's that? People run hugely diverse workloads on cpus, and they change over time.

I don't know whether it's still true, but a couple of years ago a majority of the world's CPU cycles were spent sorting things.

That's an interesting claim. Do you remember the source?
Post reply on HN