LWN: Comments on "The "branch history injection" hardware vulnerability"

OT: Question vs Statement (was The "branch history injection" hardware vulnerability)

ssmith32 — Sat, 20 Apr 2024 05:58:03 +0000

Yeah, but it was a rhetorical question - so, while framed as a question it was, in fact, a statement, not a question.

The "branch history injection" hardware vulnerability

slrtbtfs — Thu, 11 Apr 2024 10:27:23 +0000

It’s worth pointing out that Branch History Injection itself isn’t new, it’s been known since 2022.

What is new is that tooling has been developed that automates the process of finding vulnerable Code and a few gaps in the Linux Spectre Mitigations have been uncovered that way.

The "branch history injection" hardware vulnerability

cjwatson — Wed, 10 Apr 2024 19:52:02 +0000

When Spectre first came out, I seem to remember one of my then coworkers establishing that it could be used to extract administrative passwords to the company's main production private cloud from an unprivileged VM on that cloud in minutes. I would not underestimate these things if I were you.

OT: Question vs Statement (was The "branch history injection" hardware vulnerability)

dskoll — Wed, 10 Apr 2024 19:14:06 +0000

It was really a question. The word order was a bit unusual, but essentially what OP wrote was: "For how many decades has it been known that speculation could be problematic?"

The "branch history injection" hardware vulnerability

lmaoware — Wed, 10 Apr 2024 17:58:21 +0000

"It's been known for how many decades that speculation could be problematic?"

You wrote a statement not question.

The "branch history injection" hardware vulnerability

rgmoore — Wed, 10 Apr 2024 11:27:55 +0000

Yet it only comes out as we've effectively run out of means to shrink transistors further (aka: means to make more performant chips rather effortlessly).

It's been a long time since chip designers have been able to improve performance "rather effortlessly" just by taking advantage of smaller, faster transistors. Ever since processor clock speeds outran RAM fetch times, processors have depended on cache memory to avoid sitting idle while waiting for memory to load. Those caches provide an opportunity for side channel attacks, and the problem gets worse the greater the difference between clock speed and RAM fetch time.

FWIW, this is not a new problem that just appeared as a convenient excuse to force people to buy new processors. The Spectre and Meltdown paper was published more than 6 years ago, and it was exploiting problems with processors that were designed well before that. Nor were Spectre and Meltdown the first attacks to be published; there's a history of attacks using memory timing side channels going back at least 20 years.

The "branch history injection" hardware vulnerability

Heretic_Blacksheep — Wed, 10 Apr 2024 01:52:21 +0000

The problem with your statement/belief is that the only way you'll know you've been hit by Spectre exploits is if someone discovers the exploit code in the wild, rather than discovering the attacks themselves. Spectre likely won't leave smoking guns in your logs that screams "THIS IS A SPECTRE ATTACK!!!111" unlike most malware in use today.

That's one reason the industry is unaware of such attacks, another being they'd have to be targeted to the hardware revision + bypassing any mitigations in place. It's like the Log4J vulnerability. Attacks have to be semi-targeted for the environment despite the wide spread use of Log4J. Simple for intelligence agencies and some moderately skilled groups. Less so for kiddies that carry out the majority of attacks.

Low hanging fruit: this particular series of attacks generally aren't low enough on the fruit tree to be widely used. There's a lot easier targets out there including and especially the human operators. That means these kinds of attacks are going to be reserved for harder nuts to crack.

Shared resource hardware has been known to be vulnerable to many attacks, both theoretical and practical ever since the first systems became available. It was a deliberate trade off in cost versus security all the way back to the 1960s. Well, now that decision is coming back to bite the industry in the butt, viciously and without remorse. It has nothing to do with planned obsolescence and everything to do with deliberate, calculated decisions made 50+ years ago when data security could be limited to locked rooms and gentleman's agreements not to be evil. Remote access was limited to physical modems and phone lines and easily kept secure with minimal effort.

The "branch history injection" hardware vulnerability

intgr — Tue, 09 Apr 2024 20:38:50 +0000

No need to meet anyone, I believe there are multiple demos that show Spectre attacks in real-world conditions with real-world JITs, such as the JavaScript implementation in a browser. Their approaches are also documented therein.

For example https://leaky.page/

Also from the original Spectre whitepaper https://spectreattack.com/spectre.pdf

> C. Example Implementation in JavaScript
> We developed a proof-of-concept in JavaScript and tested it
> in Google Chrome version 62.0.3202 which allows a website
> to read private memory from the process in which it runs. The
> code is illustrated in Listing 2.

The "branch history injection" hardware vulnerability

ballombe — Tue, 09 Apr 2024 20:32:26 +0000

A long time ago, I made the prediction that software security would only improve through hardware improvement, like the MMU allowed separate process address space.
I would not have imagined I would be so wrong and right at the same time.

The "branch history injection" hardware vulnerability

snajpa — Tue, 09 Apr 2024 19:49:30 +0000

For the record, not that anyone cares but I still have the urge to say it: I hate these so-called vulnerabilities. Most of it smells like planned obsolescence to me, rather than a credible threat to security. It's been known for how many decades that speculation could be problematic? Yet it only comes out as we've effectively run out of means to shrink transistors further (aka: means to make more performant chips rather effortlessly).

I would love to meet someone who knows these things inside out so they can talk me through how they'd exploit these on any moderately loaded system outside of lab settings (also when the load isn't synthetic, ie. brutally predictable). And then if I take away their ability to pin a process to a specific core...