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

171–180 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#171

Post by tyfon »

ScottFree wrote: post #144
mikepurvis wrote: post #133

Earlier quoted context omitted.

Isn't GDPR supposed to be an attempt at this kind of thing, treating privacy issues as a punishable negative externality similar to pollution? I only ask because that all makes perfect sense to me, but I see a lot of negativity about GDPR on here, that all it ever does is stifle innovation and produce ever more cookie-agreement popups.

The EU has seen poor results with fines. The big tech companies (Google, Amazon, etc) pay them with the change they find in their couch cushions. Then, they continue doing whatever they want to do. It doesn't dissuade them.

We haven't really seen the "end game" deployed by the EU yet (4% of global annual turnover fines).

I suspect when that happens the companies will launch a massive PR campaign and fight it in court but eventually lose. If they pull out of the EU or pay I have no idea.

Edit: seems like 4% of alphabets 2018 global revenue [1] is "only" 5.44 billion dollars. Wonder if it can be applied multiple times.

[1] https://www.statista.com/statistics/266206/googles-annual-gl...

Re: OpenBSD was right to disable hyperthreading [video]

#172

Post by diegoperini »

x0x0 wrote: post #101
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.

Your desktop PC is regularly running largely unverified code, some of it potentially hostile: all the javascript in your browser.

Lol,

amount of untrusted dll injections to mod, by default, unmoddable games; 3rd party VR tools and drivers; video and audio multiplexer drivers; compatibility drivers for normally unsupported console cameras/controllers etc; ultra demanding last gen console emulators; macro tools that are essentialy keyloggers; anti-cheat daemons running as admin to read memory of other processes;

Windows gaming is wild! I literally sell my soul to gain a few more fps or immersion. Browser js looks almost too innocent in this whole mess.

Re: OpenBSD was right to disable hyperthreading [video]

#173

Post by vorpalhex »

dymk wrote: post #170
vorpalhex wrote: post #158

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 they didn't advertise that way. They advertised the hyperthreaded performance, without disclosing its security implications.

Re: OpenBSD was right to disable hyperthreading [video]

#174

Post by kinghajj »

Animats wrote: post #169

If you run BSD on AWS are you running a hypervisor underneath that's still doing hyperthreading? On most AWS instances, a "virtual CPU" is really a hyperthread.[1] "Each vCPU is a thread of either an Intel Xeon core or an AMD EPYC core, except for T2 and m3.medium." Is anybody actually attacking AWS this way? It seems a promising attack vector; you get to run your own code on the same machines as others. [1] https://…

I don't think that vector would work, as only a single tenant's VM is scheduled on any particular core. That's why the minimum number of vCPUs for instances on hyperthreaded hosts is 2.

Re: OpenBSD was right to disable hyperthreading [video]

#175

Post by stickfigure »

ajsnigrutin wrote: post #87
umvi wrote: post #80

Earlier quoted context omitted.

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

I know of no mass refunds (as it was with volkswagen) due to spectre/meltdown, and slowing your pc down by 30% after the first patch, and as it seems losing hyperthreading seems like a defective unit to me.

Have you asked the vendor that sold you your PC for a refund? I don't know if it would work, but that's the avenue you would have to take - including sending your PC back. Then what are you going to buy? Another PC with the same issue?

Re: OpenBSD was right to disable hyperthreading [video]

#176

Post by msla »

dwheeler wrote: post #84
mikece wrote: post #2

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

Linux came after the BSDs, so you would think the BSDs would have won. There are many reasons Linux-based systems are generally much more popular than the BSDs in the server and workstation spaces. Here's why I think that happened: * GPL vs. BSD license. Repeatedly someone in the BSD community had the bright idea of creating a proprietary OS based on a BSD. All their work was then not shared with the OSS BSD communit…

> Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well, so while others will point to that I don't think that was serious factor.

The SCO lawsuit was a joke and everyone knew it. A bare shell of a company, a mere coat rack they could hang a lawsuit on, was going up against IBM with evidence it wouldn't even release for an embarrassingly long period of time, and when it did, it was laughed out of Slashdot and Groklaw. Microsoft really didn't get its money's worth out of that little venture.

As for lawsuits against GNU, I don't know of any off the top of my head. Can you name one?

Re: OpenBSD was right to disable hyperthreading [video]

#177

Post by [deleted] »

mbauman wrote: post #112
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…

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

[deleted]

Re: OpenBSD was right to disable hyperthreading [video]

#178

Post by letstrynvm »

AnthonyMouse wrote: post #160
x0x0 wrote: post #99

Earlier quoted context omitted.

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…

The problem with fines is that they happen after the fact and only if the worst actually happens. Tons of companies have totally abominable security and never get breached only out of dumb luck. So you'll still get lots of companies playing Russian Roulette where they make higher profits for ten years before they may or may not suffer a breach and get fined into oblivion, at which point they file for bankruptcy and s…

These large rich tech companies are really responsive to 'compliance' with the letter and spirit of laws that otherwise might cause severe losses. Look at, eg, gpdr, and google suddenly getting religion about you being able to mass-download your data. Yes you can legislate solutions to corporate behaviours.

Re: OpenBSD was right to disable hyperthreading [video]

#179

Post by rrss »

throwaway2048 wrote: post #64
rrss wrote: post #60

Earlier quoted context omitted.

> there is no way to know as a kernel if two things that are security sensitive relative to each other The kernel has a way, and it is process isolation. The kernel doesn't care if you want two threads in the same process to be isolated from one another - that's your problem, not the kernel's. Anyway, thread isolation already doesn't work even without hyperthreading-specific attacks: "we have discovered that untruste…

Chrome doesn't exclusively use process isolation, several sites will share the same chrome process. This is only one example, another might be for instance, authenticating users on one thread, and sensitive authenticated data on another, which is an extremely common pattern.

Chrome turned on site isolation by default in chrome 67: https://security.googleblog.com/2018/07/mitigating-spectre-w...

My point is that the OS has no responsibility to isolate threads from one another, regardless of how many applications may try to do it themselves anyway.

Post reply on HN