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

OpenBSD was right to disable hyperthreading [video]

youtube.com

Post reply on HN
Print view View original

71–80 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#71

Post by melicerte »

robmusial wrote: post #25

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.

He also said: if you are running a system and you don't trust your users, you should definitively disable Hyperthreading.

Hence I believe hyperthreading is an option disabled for sane defaults.

Re: OpenBSD was right to disable hyperthreading [video]

#72

Post by majewsky »

UI_at_80x24 wrote: post #50
mikece wrote: post #2

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

It is if you know where to look or who to talk to. That is the exact same question I was asked ~20 years ago regarding Linux vs Windows. The barrier to entry is higher on *BSD then it is on Linux. But with the appropriate skills/time/energy it is very much worth the effort. ALL of my edge devices run OpenBSD(since 2011). Most of my Internal servers run FreeBSD (90+%), with the remainder on OpenBSD. I made the decisio…

It's hilarious how one can distinguish systemd fans and haters by how they write either "systemd" (pro) or "SystemD" (against).

Re: OpenBSD was right to disable hyperthreading [video]

#73

Post by geggam »

AnIdiotOnTheNet wrote: post #56
geggam wrote: post #44

Earlier quoted context omitted.

It still is a possibility. The Linux community is becoming a mess of things stuck together in and its getting to be really interesting to support.

The BSDs aren't really much better in that regard once you leave the base install, and their hardware support is substantially worse.

I will agree hardware still lags but for the target of servers and serving its fine.

As far as BSD being a mess after base I completely disagree. Using and understanding a package manager makes life pretty simple.

That said if the Linux community did that they would probably realize how silly containers are :)

Re: OpenBSD was right to disable hyperthreading [video]

#74

Post by umvi »

ajsnigrutin wrote: post #69

A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…

If I sell you a lock, and then 10 years later someone finds a vulnerability with the lock I sold you, should I refund you? That seems absurd. You are basically saying the product has to be perfect and the architects have to be able to see the future. Even if your hardware is formally verified, people can do physical attacks like listening to high frequency chirps of your cpu and using that to break security. Do you still deserve a refund?

There is no such thing as perfect security. It is a cat and mouse game that will continue until the end of time, requiring ever greater resources. Therefore... all software and hardware should be free because all software and hardware is defective?

Re: OpenBSD was right to disable hyperthreading [video]

#75

Post by Crinus »

ajsnigrutin wrote: post #69

A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…

Isn't the reason that technically the CPU is still fast and it is the OS (that is outside Intel's control) that slows it down? And AFAIK all OSes can disable these mitigations (are they even a concern for personal computers, especially for cases like gaming?) so if you really want you can get your performance back.

Re: OpenBSD was right to disable hyperthreading [video]

#76

Post by Crinus »

admax88q wrote: post #41
dooglius wrote: post #38

Earlier quoted context omitted.

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.

Because sane defaults are important.

Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.

Re: OpenBSD was right to disable hyperthreading [video]

#77

Post by ajsnigrutin »

umvi wrote: post #74
ajsnigrutin wrote: post #69

A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…

If I sell you a lock, and then 10 years later someone finds a vulnerability with the lock I sold you, should I refund you? That seems absurd. You are basically saying the product has to be perfect and the architects have to be able to see the future. Even if your hardware is formally verified, people can do physical attacks like listening to high frequency chirps of your cpu and using that to break security. Do you s…

10 years? Of course not. But if i bought it yesterday, I'd expect a refund. Just consider that they were still selling affected CPUs even when they knew about the vulnerabilities and even after the papers were published.

Re: OpenBSD was right to disable hyperthreading [video]

#78

Post by [deleted] »

ajsnigrutin wrote: post #69

A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…

[deleted]

Re: OpenBSD was right to disable hyperthreading [video]

#79

Post by marmaduke »

throw0101a wrote: post #26
thefz wrote: post #6

Earlier quoted context omitted.

IIRC Netflix is using FreeBSD. Outside the server scope, OSX is mainly BSD with a different kernel. FreeNAS is based on FreeBSD too.

NetApp, Dell-EMC Isilon, Juniper, iXsystems, pfSense, etc: * https://en.wikipedia.org/wiki/List_of_products_based_on_Free... If you follow the commit logs, you'll regularly see "Sponsored by" messages: * https://www.freshsource.org/commits.php Not just for the core OS, but also in ports and also drivers (Intel, Chelsio, Mellonox). FreeBSD in particular has always been persnickety about acknowledging work done on beha…

Not all EMC systems are FreeBSD; at least the VNX I managed is a Linux derivative

Re: OpenBSD was right to disable hyperthreading [video]

#80

Post by umvi »

ajsnigrutin wrote: post #77
umvi wrote: post #74

Earlier quoted context omitted.

If I sell you a lock, and then 10 years later someone finds a vulnerability with the lock I sold you, should I refund you? That seems absurd. You are basically saying the product has to be perfect and the architects have to be able to see the future. Even if your hardware is formally verified, people can do physical attacks like listening to high frequency chirps of your cpu and using that to break security. Do you s…

10 years? Of course not. But if i bought it yesterday, I'd expect a refund. Just consider that they were still selling affected CPUs even when they knew about the vulnerabilities and even after the papers were published.

> Of course not. But if i bought it yesterday, I'd expect a refund.

If you bought it yesterday, why wouldn't you be able to get a refund? I don't know of any major vendor that would deny you a refund on grounds that the unit is defective.

Post reply on HN