OpenBSD was right to disable hyperthreading [video] • Hacker News Board

Re: OpenBSD was right to disable hyperthreading [video]

#201

Post by Forbo » Tue, Sep 03, 2019, 9:15 PM UTC

dymk wrote: post #195

vorpalhex wrote: post #173

Earlier quoted context omitted.

Except they didn't advertise that way. They advertised the hyperthreaded performance, without disclosing its security implications.

You're asking for something impossible. Lock manufacturers can't advertise that their locks are hardened against specific yet-to-be-discovered attacks. Intel can't advertise that their CPUs are hardened against specific yet-to-be-discovered attacks. They can only provide mitigations after the fact.

Yet they are still advertising the number of threads without any mention of the vulnerabilities involved, well after those vulnerabilities have been disclosed. It's deceptive advertising at best.

Re: OpenBSD was right to disable hyperthreading [video]

#202

Post by rrss » Tue, Sep 03, 2019, 9:19 PM UTC

derpherpsson wrote: post #111

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…

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.

> should have understood that they sacrificed security for speed

And what if they didn't?

It's pretty much exactly like that. Intel has been making CPUs for well over a decade that are vulnerable to various side channel attacks, and the only thing that has changed is the community's understanding of the vulnerabilities (i.e. there's a new way to pick the lock).

Re: OpenBSD was right to disable hyperthreading [video]

#203

Post by rhaps0dy » Tue, Sep 03, 2019, 9:22 PM UTC

voldacar wrote: post #125

dleslie wrote: post #9

History will show that Theo was right in a manner similar to how Stalman was right: technically correct analysis and eerily accurate predictions, but lacking in sufficient charisma to create more than a small following. To some extent, you might say they are like Cassandra; speaking the truth but not believed or listened to.

I think Stallman is more of a Tiresias

How so? I had to look Tiresias up on Wikipedia, a blind prophet, but I still don't see the connection. Would it be possible for you to please explain?

Re: OpenBSD was right to disable hyperthreading [video]

#204

Post by rrss » Tue, Sep 03, 2019, 9:24 PM UTC

mbauman wrote: post #200

rrss wrote: post #198

Earlier quoted context omitted.

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

One quick google later: https://www.intel.com/content/www/us/en/architecture-and-tec... > By combining one of these Intel® processors and chipsets with an operating system and BIOS supporting Intel® HT Technology, you can: > * Run demanding applications simultaneously while maintaining system responsiveness > * Keep systems protected , efficient, and manageable while minimizing impact on productivity

I have no idea what "keep systems protected" means (and probably neither did the person who wrote that).

That statement is a long way from an actual guarantee that there is no way for one logical thread to extract information about another.

Re: OpenBSD was right to disable hyperthreading [video]

#205

Post by smhenderson » Tue, Sep 03, 2019, 9:37 PM UTC

stock_toaster wrote: post #184

smhenderson wrote: post #156

Earlier quoted context omitted.

Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well Do you mean the SCO lawsuit against IBM? Because I would argue that 1) that happened long enough after Linux had established itself that people were too invested to be immediately scared off and 2) people put a lot of faith in IBM and there legal team to defend Linux. I think the community around Linux was able to…

> Do you mean the SCO lawsuit against IBM? No, pretty sure the parent meant the the USL vs BSDi one. Though I disagree with the parent, and believe it _was_ impactful on BSD adoption. https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.... .

I meant the part where he mentioned but there was lawsuit-rattling for Linux and GNU as well.

I don’t remember anything before SCO so I was curious if there was something before that I missed.

I must admit I was downright obsessed with that case and Groklaw’s coverage at the time so I guess it’s not surprising that it was the first thing I thought of...

Re: OpenBSD was right to disable hyperthreading [video]

#206

Post by yazaddaruvala » Tue, Sep 03, 2019, 9:38 PM UTC

dleslie wrote: post #9

History will show that Theo was right in a manner similar to how Stalman was right: technically correct analysis and eerily accurate predictions, but lacking in sufficient charisma to create more than a small following. To some extent, you might say they are like Cassandra; speaking the truth but not believed or listened to.

lol, I enjoyed it, but you might consider citing any greek mythology when its obscure and easily confused with a database.

Re: OpenBSD was right to disable hyperthreading [video]

#207

Post by throwaway2048 » Tue, Sep 03, 2019, 9:40 PM UTC

homologate wrote: post #159

ebog wrote: post #120

Earlier quoted context omitted.

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.

Do you have a similar opinion in regards to crimes? Do you think that there will be less crime if there are harsher prison sentences? Are you in favor of mandatory minimum sentences? If not, why do you think harsher punishments are needed here but not for crimes?

Do you think there would be less murders or more if there was no punishment at all for murdering people?

That's where we are atm with security breaches.

Re: OpenBSD was right to disable hyperthreading [video]

#208

Post by yjftsjthsd-h » Tue, Sep 03, 2019, 9:48 PM UTC

homologate wrote: post #159

ebog wrote: post #120

Earlier quoted context omitted.

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.

Do you have a similar opinion in regards to crimes? Do you think that there will be less crime if there are harsher prison sentences? Are you in favor of mandatory minimum sentences? If not, why do you think harsher punishments are needed here but not for crimes?

Compared to effectively zero penalty, probably.

Re: OpenBSD was right to disable hyperthreading [video]

#209

Post by yjftsjthsd-h » Tue, Sep 03, 2019, 9:50 PM UTC

ryacko wrote: post #181

red_phone wrote: post #105

Earlier quoted context omitted.

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.

They could still require redistributions to include a copyright notice. I think the real issue is that Intel might engage in product binning without changing the source code.

I'm pretty they just forgot. MINIX is under a license that does actually still require a copyright notice, and I'm pretty sure that after the news came out about it being used, they went and fixed the fact that they'd apparently forgotten to include it.

Re: OpenBSD was right to disable hyperthreading [video]

#210

Post by muricula » Tue, Sep 03, 2019, 9:57 PM UTC

dnautics wrote: post #31

dnautics wrote: post #10

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.

Close but not quite -- sibling hyperthreads (logical cores) share cache state. Physical cores do not share cache state. Different processes, threads, or VMs on sibling hyperthreads (by definition on the same physical core) can infer the other's memory state based on the cache state.

If an attacker is pinned to one hyperthread, and the victim is pinned to another which isn't a sibling hyperthread, none of the spectre attacks will work since the cache state isn't shared.

As an attacker with code exec on a core, you can theoretically play games with the OS scheduler until you're running on a sibling core with your victim thread/process/vm.