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

111–120 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#111

Post by derpherpsson »

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…

Its not like that.

Intel took shortcuts to make their CPUs faster. At least some of the chip architects working on their implementation of hyperthreading should have understood that they sacrificed security for speed - without telling anyone.

Re: OpenBSD was right to disable hyperthreading [video]

#112

Post by mbauman »

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…

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

Re: OpenBSD was right to disable hyperthreading [video]

#113

Post by toast0 »

floatingatoll wrote: post #91
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…

Locks often offer a lifetime warranty against manufacturing defects in their locks. Is this a manufacturing defect in CPUs? (The defect is baked into hard silicon out in the world, so the analogy is plausible.)

This is a design defect, not a manufacturing defect.

In case of design defects in highly regulated fields (cars), there is often a campaign to make things right. When Intel processors couldn't divide properly, they had a campaign to replace them. In this case, it looks like we're not getting much.

Re: OpenBSD was right to disable hyperthreading [video]

#114

Post by Wowfunhappy »

AndrewUnmuted wrote: post #103
Crinus wrote: post #76

Earlier quoted context omitted.

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.

HT doesn't actually make video encoding go any faster. It just allows the system to remain more stable while performing some other task at the same time. You really should not be running other tasks on your system while encoding video, your encoder will need all the resources it can get.

Uh, are you sure of that? My experience has been that x264, for instance, benefits greatly from hyperthreading.

Hyperthreading allows you to queue up additional instructions (in a different thread) that the executor can switch to when it would otherwise be just waiting for the next instruction in the primary thread.

Re: OpenBSD was right to disable hyperthreading [video]

#115

Post by big_chungus »

mikece wrote: post #2

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

In some places they are. For instance, net flix appliances use FreeBSD. One of the deciding factors here is licensing: Linux is gpl, meaning net flix would have to contribute back its changes, whereas by using a BSD-licensed alternative, it can keep those changes in-house for a performance advantage. You can dispute the merits or ethics of this, but that's the choice a good few people make. I believe yahoo used it for similar reasons. Some consoles (Sony Play Station 3, Nintendo Switch, possibly others?) use it internally, again so they don't have to open-source console code. Others use it for appliance-type devices, again for similar reasons.

Re: OpenBSD was right to disable hyperthreading [video]

#118

Post by derpherpsson »

AnIdiotOnTheNet wrote: post #54
marcosdumay wrote: post #40

Earlier quoted context omitted.

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.

Generally people prefer stuff that works over stuff that is nebulously "more secure".

Stuff breaks when it is hacked.

State actors are now targeting whole populations. It takes less and less time to enumerate the entire IPv4 address space. Knowledge about hacking is becoming more and more accessible to a larger group of people. This problem is not going away - it is growing larger for every year.

If you don't believe me: Just attach an object to the internet and watch the logs.

Re: OpenBSD was right to disable hyperthreading [video]

#119

Post by Syzygies »

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 of the best cpu without hyperthreading. That would today be the i7-9700 @ 5.1GHz for $400.

Re: OpenBSD was right to disable hyperthreading [video]

#120

Post by ebog »

x0x0 wrote: post #99
ScottFree wrote: post #90

Earlier quoted context omitted.

Does that apply here? The BSD guys chose security over speed, as is their mantra, but companies that run linux for profit prioritize speed and cost per computing unit over security. I think 'disable hyperthreading' would be a difficult sell even for Steve Jobs.

This is why we need enormous fines for security breaches, and smaller fines just for not following best practices. Right now, only the people worried about paying more for performance, dev time, or security engineers are listened to. We need the legal teams inside companies to have something more substantial than possible negative publicity with which to motivate the CEO and CTO as a countervailing balance. Just like…

Don't know why you're comment is grayed, we absolutely need heavy monetary penalties for the worst kinds of data breaches. The abstract idea of a class action lawsuit isn't enough, even after the Equifax breach.
Post reply on HN