Live data from Hacker News

OpenBSD was right to disable hyperthreading [video]

youtube.com

231–240 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#231
post #122

Earlier quoted context omitted.

Because the large companies that deploy hundreds of thousands of servers need to hire lots and lots of people to make or maintain local enhancements, at all levels from the OS to libraries and utilities. In that environment it's not hard to make a local change that saves a million dollars in running-hardware costs, and it's also not hard to find Linux developers to make those changes. OpenBSD developers? Not so much.…

The kernel teams at most large companies, even large tech companies, are not that big. Sure, the pool of currently experienced Linux kernel developers is large compared to the BSDs, but if you hire a smart person (like a Linux kernel developer), and provide them with means, opportunity, and motive you'll have a BSD kernel developer soon enough. Commercial support and network effects and costs of running multiple oper…

>The kernel teams at most large companies, even large tech > companies, are not that big.

It's not just about the kernel. You're talking about entire ecosystems of core utilities, filesystems, network stacks, security mechanisms, virtualization and resource-control subsystems (e.g. cgroups), performance profiling and tuning, etc. They're different systems from top to bottom, just like when I switched from 4.3 to V.2 thirty years ago.

> Commercial support

Stop right there. FAANG companies aren't going to buy support contracts. They'll hire the maintainers instead (like they did with me and hundreds of others like me at my current company). They're not going to split that effort across multiple platforms. They'll focus on one, then hire thousands of developers who don't even realize the tools and interfaces they use are Linux-specific. Then all of the wannabes will copy them, for the reasons I already mentioned. The network effect has gone way beyond any chance of reversal. Sorry.

Re: OpenBSD was right to disable hyperthreading [video]

#232

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.

Are scripts loaded in a web browser considered "users". If so, don't most people run systems which cant trust all of their users?

Re: OpenBSD was right to disable hyperthreading [video]

#233
post #42

Earlier quoted context omitted.

> but lacking in sufficient charisma to create more than a small following. IMO it's not that Linus has more charisma than Theo, it's simply the network effect of one project over the other.

The difference is because of the license. GPL license (created by Stallman, btw) won over BSD license. The emergence of a GPL-licensed kernel was inevitable. If Linux didn't appear when it did, some other kernel would appear. Maybe folks would have more motivation to work on Hurd, and it would be the main kernel for everything now.

Why is that the case? Isn't the BSD license more relaxed? I would think companies like RedHat would have liked the BSD license more.

Re: OpenBSD was right to disable hyperthreading [video]

#234

I disable hyperthreading for better performance. In my experience as a mathematician building parallel compute servers, hyperthreading generates more heat than it is worth. I can overclock further without hyperthreading, to more than overtake the faint advantage that hyperthreading offers at a given clock speed. So I now buy binned, delidded processors from Silicon Lottery, choosing the best reasonably priced speed o…

The number of generations of processors where this has been true is really astounding to me. It really makes me wonder why they persist with this line of effort instead of doing something else, like cores that share logic units only.

Because for a large number of workloads, hyperthreading gives real performance improvements.

The vast majority of consumers aren't running compute heavy workloads that are more amenable to SIMD work (which it sounds like this might be) than the sort of highly branching, often stalled work that general purpose programs do.

Re: OpenBSD was right to disable hyperthreading [video]

#235

Earlier quoted context omitted.

Minix only has a "huge install base" because of Intel ME firmware junk. Its not really meaningful, because the firmware could be pretty much any arbitrary OS and it would make zero difference to any end user. Tannenbaum himself didnt even know about Intel using MINIX in their ME firmware until recently, so that should show you how much relevance it has.

This is, at least in part, a result of MINIX using a highly permissive license. It’s easier to use an open source OS in relative secrecy if you aren’t required to release your modifications. And an organization with deep technical expertise like Intel would not likely need much assistance from the community for their implementation.

> This is, at least in part, a result of MINIX using a highly permissive license.

Not at all. MINIX was actually Intel's second choice, they tried first to fit Linux into their new x86 based ME. But the maintainers were uncooperative:

https://www.phoronix.com/scan.php?page=news_item&px=MTY4MzM

Intel then submitted similar patches to the MINIX kernel, which subsequently got accepted.

https://www.cs.vu.nl/~ast/intel/

Re: OpenBSD was right to disable hyperthreading [video]

#236
Full interview: https://www.youtube.com/watch?v=sDrRvrh16ws

One of the things the Linux kernel developer says in the interview is that researchers are going through Intel patents to find "security bugs".

He says this is "fun". Twice. He seems pretty nonchalant about these issues. Like it is great to fix them, but not like it is too important or anything to worry about. He says what is most important to him is that Linux "succeeds". The attitude is reminiscient of Microsoft in their heyday. Drunk on success. He even calls out a Microsoft employee he is working with. He says the companies contribute "selfishly". This is no different from BSD. Users do not determine how much security is prioritized, the contributors do. However, what happens when the biggest kernel contributors are companies?

He also indicates he does not agree with Stallman philosophically on technology issues. We do not get any details of the specifics of their disagreement.

As a user, I think is it somewhat easier to keep track of Net/OpenBSD kernel contributions than it is to keep track of Linux kernel contributions. I might be wrong on that. As far as I can tell, the biggest contributors to Net/OpenBSD kernels are still individuals and are not acting directly on behalf of corporations.

Re: OpenBSD was right to disable hyperthreading [video]

#237
post #198

Earlier quoted context omitted.

Downvoted for the straw man — Intel is currently selling processors with, e.g., 8 cores and 16 threads without any asterisks or caveats. That's in their official marketing materials. Currently. https://a.sellpoint.net/a/Qo3wL1no.jpg (via NewEgg) https://www.intel.com/content/www/us/en/products/processors/...

And it's true... Has Intel ever said "we guarantee that hyperthreads are entirely isolated from one another?"

All car makers put asterisk when talk about performance and mileage - it didn't help VW from being fined and prosecuted.

We were given certain benchmark numbers and performance target and it all went to shit with a single microcode update.

Somehow most people expect CPU not to give random javascript in the Internets a private key from encrypted file system.

Intel got off so easy from that drama. Imagine a car marker selling you a car 4 seats, but when backseats are used you might lose steering? Would that be okay? No where it says you get 4 usable seats.

Re: OpenBSD was right to disable hyperthreading [video]

#238
post #170

Earlier quoted context omitted.

When the Kaba Simplex (a commercial door lock) was discovered to be easily bypassed by holding a magnet near it, yes, it was in fact a design defect and the company had to correct it by giving repair kits out to purchasers.

Intel and others did give out a repair kit; they give you the option of disabling hyperthreading and a whole host of other optimizations. Those optimizations are both what provides this new side-channel of attack, and an immense speedup when they're enabled. You can't have one without the other.

Except lock buyers still go the door lock and in case of intel you lost threads.

Re: OpenBSD was right to disable hyperthreading [video]

#240
post #239
post #162

Earlier quoted context omitted.

You can. Click on the timestamp of the comment, and then click "favorite"

Woah thanks. Dunno why someone downvoted this lol

I'm not sure, but commenting on downvoting is likely to attract downvotes as it's explicitly against the guidelines.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN