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

131–140 of 158 posts

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

#131

Post by orf »

temprature wrote: post #129
orf wrote: post #108

Earlier quoted context omitted.

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

OpenBSD and DragonFly had their meltdown mitigations done in a couple of weeks from when it was publicly disclosed. If it's good enough for projects developed by handfuls of volunteers, it's good enough for the multi-hundred billion dollar megacorps.

So you're saying if a small software operation can put in place mitigations in X time then a absolutely massive hardware operation with hundreds of product lines consisting of some of the most advanced, ridiculously complex, slow to develop chips in the world can push a fix to many billions of devices in X time as well, whilst ensuring backwards compatibility and reducing the performance impact across the mind mindbogglingly large number of different workloads that their chips are used for.

Makes sense. 90 days is more than enough.

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

#132

Post by krylon »

letsgetphysITal wrote: post #120
krylon wrote: post #112

Earlier quoted context omitted.

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.

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

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

#134

Post by temprature »

orf wrote: post #131
temprature wrote: post #129

Earlier quoted context omitted.

OpenBSD and DragonFly had their meltdown mitigations done in a couple of weeks from when it was publicly disclosed. If it's good enough for projects developed by handfuls of volunteers, it's good enough for the multi-hundred billion dollar megacorps.

So you're saying if a small software operation can put in place mitigations in X time then a absolutely massive hardware operation with hundreds of product lines consisting of some of the most advanced, ridiculously complex, slow to develop chips in the world can push a fix to many billions of devices in X time as well, whilst ensuring backwards compatibility and reducing the performance impact across the mind mindbo…

Implementing KPTI didn't involve any of what you just said.

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

#135

Post by keldaris »

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…

As I already implied in the parent post, I've no doubt we'll see more Spectre-like issues and I don't find it hard to believe that there's yet another embargo going on, that something's leaked again and that the OpenBSD people have picked up on it. I'm just curious about how many tradeoffs in performance and usability OpenBSD would be willing to make (in the form of default settings, I'm aware this one can be toggled) in the pursuit of security and how they do the cost/benefit analysis, because their process seems vastly different from that of the main OS vendors.

On the latter point, I did take "strongly suspect" at face value rather than code for "we know for sure, just can't disclose it all yet" because I'm not familiar with the development culture of OpenBSD.

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

#136

Post by orf »

temprature wrote: post #134
orf wrote: post #131

Earlier quoted context omitted.

So you're saying if a small software operation can put in place mitigations in X time then a absolutely massive hardware operation with hundreds of product lines consisting of some of the most advanced, ridiculously complex, slow to develop chips in the world can push a fix to many billions of devices in X time as well, whilst ensuring backwards compatibility and reducing the performance impact across the mind mindbo…

Implementing KPTI didn't involve any of what you just said.

Exactly. So how can you compare the work that's required from Intel to patch the flaw in new designs + mitigate it with microcode vs the work that's required from 'projects developed by handfuls of volunteers'?

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

#137

Post by temprature »

keldaris wrote: post #135
temprature wrote: post #128

Earlier quoted context omitted.

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…

As I already implied in the parent post, I've no doubt we'll see more Spectre-like issues and I don't find it hard to believe that there's yet another embargo going on, that something's leaked again and that the OpenBSD people have picked up on it. I'm just curious about how many tradeoffs in performance and usability OpenBSD would be willing to make (in the form of default settings, I'm aware this one can be toggled…

Nice backpedaling.

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

#138

Post by keldaris »

temprature wrote: post #137
keldaris wrote: post #135

Earlier quoted context omitted.

As I already implied in the parent post, I've no doubt we'll see more Spectre-like issues and I don't find it hard to believe that there's yet another embargo going on, that something's leaked again and that the OpenBSD people have picked up on it. I'm just curious about how many tradeoffs in performance and usability OpenBSD would be willing to make (in the form of default settings, I'm aware this one can be toggled…

Nice backpedaling.

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.

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

#139

Post by ams6110 »

keldaris wrote: post #135
temprature wrote: post #128

Earlier quoted context omitted.

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…

As I already implied in the parent post, I've no doubt we'll see more Spectre-like issues and I don't find it hard to believe that there's yet another embargo going on, that something's leaked again and that the OpenBSD people have picked up on it. I'm just curious about how many tradeoffs in performance and usability OpenBSD would be willing to make (in the form of default settings, I'm aware this one can be toggled…

Though it doesn't answer your question directly, the project goals are here: https://www.openbsd.org/goals.html. Security is important, but not the only goal. Notice that the word "performance" does not appear on this page.

If you want performance above all else, OpenBSD is not for you.

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

#140

Post by bigato »

keldaris wrote: post #138
temprature wrote: post #137

Earlier quoted context omitted.

Nice backpedaling.

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 people will prefer the peace of mind of knowing that safe defaults are in place if they don't change anything. Those will probably align with OpenBSD here. Some people believe that security is something you bolt on afterwards. Those definitely won't like OpenBSD design decisions.

Post reply on HN