Live data from Hacker News

OpenBSD was right to disable hyperthreading [video]

youtube.com

31–40 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#31

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

actually I just took a shower and answered my question (I think) - many of the hyperthreading bugs don't breach the process divide, they use errors in hyperthreading statefulness to use a side channel to breach memory divide, and the cores share memory, whether or not who's on what core, if any one core gets compromised, you could potentially access any of the core's memory.

Re: OpenBSD was right to disable hyperthreading [video]

#32

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

You have to be absolutely sure that your tenants are not executing arbitrary code (i.e. javascript) because then they can get compromised, too.

Re: OpenBSD was right to disable hyperthreading [video]

#33

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

[deleted]

Re: OpenBSD was right to disable hyperthreading [video]

#34
post #4
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

I'd say, release early, release often. In general, *BSDs take more time to work out technical details, make sure that the design is right. The approach in the Linux communtity is much more, release something that mostly works now and fix it later.

Ubuntu kicking everyone into a 6 month release cycle pushed Linux, as a kernel and as a software ecosystem, forward a lot. Quality and quantity seem to converge over a long enough view.

Re: OpenBSD was right to disable hyperthreading [video]

#35
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

At a time when the commercial BSD companies were fighting among themselves and allowing their technology to become stale and remain expensive, Linux came along with RedHat and SuSE.

Those two made an effort to meet directly with business leaders, attend all the trade shows, and gave their product away for free. Their model was at least as shocking as their license; hitherto, hardly any business software was free and paired with consulting services. It caused a storm, and gave birth to a whole industry that wasn't possible under the expensive BSD model.

Re: OpenBSD was right to disable hyperthreading [video]

#36

For those that can't watch the video GregKH says that OpenBSD was right to disable hyper-threading earlier than Linux in response to Spectre and Meltdown and now Linux disables it too. He also caveats it by saying they were right for "a little bit of the wrong reasons" but at least in this clip doesn't expand on what he meant by that or what those wrong reasons were or why they were wrong.

[deleted]

Re: OpenBSD was right to disable hyperthreading [video]

#37
post #27
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

Because you can get the same technical outcome with using off the shelf Linux and setting it up to be conservative just like OpenBSD. (Or simply run sensitive workloads on separated/isolated machines.) The dreaded TCO is likely lower with Linux, because it's easier to work with, better drivers, better performance, more software available natively, and so on. (The whole Linux ecosystem seems more efficient for busines…

> setting it up to be conservative just like OpenBSD

Meh. Probably for superficial stuff, yes. But would Linux kill cat(1) if it did some network calls? I bet not. See https://www.openbsd.org/innovations.html

Re: OpenBSD was right to disable hyperthreading [video]

#38

For those that can't watch the video GregKH says that OpenBSD was right to disable hyper-threading earlier than Linux in response to Spectre and Meltdown and now Linux disables it too. He also caveats it by saying they were right for "a little bit of the wrong reasons" but at least in this clip doesn't expand on what he meant by that or what those wrong reasons were or why they were wrong.

Why should the kernel be making this decision at all, rather than leaving it up to the distro or a command-line boot argument?

EDIT: can't see the video so if it is just a default rather than a forced disablement that's fine.

Re: OpenBSD was right to disable hyperthreading [video]

#39

For those that can't watch the video GregKH says that OpenBSD was right to disable hyper-threading earlier than Linux in response to Spectre and Meltdown and now Linux disables it too. He also caveats it by saying they were right for "a little bit of the wrong reasons" but at least in this clip doesn't expand on what he meant by that or what those wrong reasons were or why they were wrong.

Why should the kernel be making this decision at all, rather than leaving it up to the distro or a command-line boot argument? EDIT: can't see the video so if it is just a default rather than a forced disablement that's fine.

defaults matter

Re: OpenBSD was right to disable hyperthreading [video]

#40
post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

It has lower performance than Linux, and some compatibility problems that appear once in a while.

It used to be fashionable to run BSD on security focused machines (like firewalls). I'm not sure why Linux won there too.

Post reply on HN