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

81–90 of 158 posts

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

#81

Post by girvo »

mtgx wrote: post #54
timvisee wrote: post #36

Earlier quoted context omitted.

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

And it's a mistake. Just recently I noticed that when Firefox loads multiple tabs of the same wordpress site, it starts hanging not unlike Firefox always used to hang. That's likely because it groups all of those same site pages under one process. I've never experienced that with Chrome. This is why I hope Firefox eventually (ASAP) switches to one process per tab, too. I can handle the browser using an extra GB of RA…

> I've never experienced that with Chrome

Right, but I doubt that it's for exactly the reason you think it is: Chrome doesn't blindly do "one process per tab" anymore, and hasn't for a bit.

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

#82

Post by naikrovek »

adrianratnapala wrote: post #67
ajross wrote: post #30

Earlier quoted context omitted.

In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…

> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?

> How often is that a polite way of saying "software that is inefficient"?

One could also say "software written with strong OOP patterns" because those are almost always written to benefit the developer later, rather than the CPU and RAM at runtime.

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

#83

Post by da_chicken »

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…

> it seems that OpenBSD is an operating system built mainly for OpenBSD developers

Honestly, I would say that this is true of many open source projects. It's one of the reasons that open source development tools are so good on Linux, but end user applications fall so far behind. It's also why documentation and usability tend to be much worse. When your system is based on volunteering, the work that gets done tends to be the stuff that interests the workers.

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

#84

Post by nbsd4life »

petee wrote: post #79
nbsd4life wrote: post #75

Earlier quoted context omitted.

This comment finally put the puzzle pieces for why so many people seem to hate this website.

A) Whom? B) Why? I can't see this flagged post, but the user in question has such quality comments as "hahahaha", "ouch", and "duhhh" -- most users here actually contribute to discussion, where as a few think this is reddit...

It's extremely punishing of negative-sounding comments. People who want to call out bullshit on the orange website end up doing it on other forums so it looks like they hate it a lot.

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

#85

Post by the8472 »

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…

> Given that hyperthreads share L1 cache, this might also be better for performance.

If userspace thread writes something into a buffer, does some syscall initiating asynchronous work in the kernel wouldn't it be better for the kernel thread to be located on the same core instead of shuffling the data into another cache?

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

#86

Post by throwaway2048 »

nbsd4life wrote: post #84
petee wrote: post #79

Earlier quoted context omitted.

A) Whom? B) Why? I can't see this flagged post, but the user in question has such quality comments as "hahahaha", "ouch", and "duhhh" -- most users here actually contribute to discussion, where as a few think this is reddit...

It's extremely punishing of negative-sounding comments. People who want to call out bullshit on the orange website end up doing it on other forums so it looks like they hate it a lot.

Nobody here wants to look at generic comments that shit all over things, if you have something of value to say, say it, otherwise go away, nobody is going to miss you.

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

#87

Post by ajross »

adrianratnapala wrote: post #67
ajross wrote: post #30

Earlier quoted context omitted.

In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…

> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?

Often. But software is what software does, and a CPU that only worked well on "efficient" code will always fail when compared with one that runs the junk faster than the competition.

Also, to be fair: sometimes a DRAM fetch is just inherent in the problem. Big RAM-resident databases are all about DRAM latency because while sure, it's a lot slower than L1 cache, it's still faster than flash. I mean, memcached is a giant monument in praise of the pipeline stall, and it's hugely successful.

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

#88

Post by forapurpose »

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…

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

In fairness, my impression from the video of Theo's presentation was that they were tipped off by someone under embargo.

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

#89

Post by forapurpose »

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…

> they "strongly suspect" (but don't know and haven't shown)

Some security professionals seem to insist on having a proven exploit before they act. Doesn't that seem like poor decision-making? Their job is to provide security, not to secure proven exploits - the latter is a means to an end. If there are threats from unknown exploits, and there certainly are, then it seems that they need techniques to address unknown exploits. One of those techniques is expert analysis of potential threats.

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

#90

Post by adrianratnapala »

ajross wrote: post #87
adrianratnapala wrote: post #67

Earlier quoted context omitted.

> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?

Often. But software is what software does, and a CPU that only worked well on "efficient" code will always fail when compared with one that runs the junk faster than the competition. Also, to be fair: sometimes a DRAM fetch is just inherent in the problem. Big RAM-resident databases are all about DRAM latency because while sure, it's a lot slower than L1 cache, it's still faster than flash. I mean, memcached is a gia…

> But software is what software does, and a CPU that only

Indeed. It is arguably rational for Intel to take on the burden in a centralised place rather than expecting every two-bit software shop to to do it.

But then the existence of this kind of security issue shows that the added complexity is not always worthwhile. We might be forced to to accept that computers which actually behave well are a little bit slower than we thought. But in return they will be simpler and more amenable to software optimisation.

Post reply on HN