Back

Branch Privilege Injection: Exploiting branch predictor race conditions

421 points18 dayscomsec.ethz.ch

See also: ETH Zurich researchers discover new security vulnerability in Intel processors - https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth...

dang18 days ago

Thanks! We've changed the URL above from the university press release (https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth...) to that first link.

ncr10018 days ago

Impact illustration:

> [...] the contents of the entire memory to be read over time, explains Rüegge. “We can trigger the error repeatedly and achieve a readout speed of over 5000 bytes per second.” In the event of an attack, therefore, it is only a matter of time before the information in the entire CPU memory falls into the wrong hands.

formerly_proven18 days ago

Prepare for another dive maneuver in the benchmarks department I guess.

tsukikage18 days ago

We need software and hardware to cooperate on this. Specifically, threads from different security contexts shouldn't get assigned to the same core. If we guarantee this, the fences/flushes/other clearing of shared state can be limited to kernel calls and process lifetime events, leaving all the benefits of caching and speculative execution on the table for things actually doing heavy lifting without worrying about side channel leaks.

+1
tankenmate18 days ago
immibis18 days ago

how will this prevent JavaScript from leaking my password manager database?

cenamus18 days ago

And if not, why did they introduce severe bugs for a tiny performance improvement?

+4
bloppe18 days ago
+3
umanwizard18 days ago
trebligdivad18 days ago

Thanks! It would be great if someone could update the title URL to that blog post; the press release is worse than useless.

dang18 days ago
alberto-m18 days ago

I don't know guys. Yes, the direct link saves a click, but the original title was more informative for the casual reader. I'm not a professional karma farmer and in dang's shoes I would have made the same adjustment, but I can't deny that seeing the upvote rate going down by 75% after the change was a little harsh.

+1
dang17 days ago
trebligdivad18 days ago

Thanks!

eigenform18 days ago

Great read! Some boiled-down takeaways:

- Predictor updates may be deferred until sometime after a branch retires. Makes sense, otherwise I guess you'd expect that branches would take longer to retire!

- Dispatch-serializing instructions don't stall the pipeline for pending updates to predictor state. Also makes sense, considering you've already made a distinction between "committing the result of the branch instruction" and "committing the result of the prediction".

- Privilege-changing instructions don't stall the pipeline for pending updates either. Also makes sense, but only if you can guarantee that the privilege level is consistent between making/committing a prediction. Otherwise, you might be creating a situation where predictions generated by code in one privilege level may be committed to state used in a different one?

Maybe this is hard because "current privilege level" is not a single unambiguous thing in the pipeline?

mettamage18 days ago

Good to see Kaveh Razavi, he used to teach at my uni in the Vrije Universiteit in Amsterdam :) The course Hardware Security was crazy cool and delved into stuff lijke this.

markus_zhang18 days ago

I checked out this course (and another one from Vrije about malware) a couple of years ago, back then there was very little public info about the courses.

Do you know if there is any official recording or notes online?

Thanks in advance.

thijsr18 days ago

As far as I am aware, the course material is not public. Practical assignments are an integral part of the courses given by the VUSEC group, and unfortunately those are difficult to do remotely without the course infrastructure.

The Binary and Malware Analysis course that you mentioned builds on top of the book "Practical Binary Analysis" by Dennis Andriesse, so you could grab a copy of that if you are interested.

mettamage18 days ago

Ah yea, he gave a guest lecture on how he hacked a botnet!

More info here: https://krebsonsecurity.com/2014/06/operation-tovar-targets-...

it's been a while back :)

markus_zhang18 days ago

Thanks. I understand that it is difficult to do it remotely.

I do have the book! I bought it a while ago but did not have the pleasure to check it out.

mettamage18 days ago

No, but last time I checked you can be a contracted student for 1200 euro's.

If I knew what I was getting into at the time, I'd do it. I did pay for extra, but in my case it was the low Dutch rate, so for me it was 400 euro's to follow hardware security, since I already graduated.

But I can give a rough outline of what they taught. It has been years ago but here you go.

Hardware security:

* Flush/Reload

* Cache eviction

* Spectre

* Rowhammer

* Implement research paper

* Read all kinds of research papers of our choosing (just use VUSEC as your seed and you'll be good to go)

Binary & Malware Analysis:

* Using IDA Pro to find the exact assembly line where the unpacker software we had to analyze unpacked its software fully into memory. Also we had to disable GDB debug protections. Something to do with ptrace and nopping some instructions out, if I recall correctly (look, I only low level programmed in my security courses and it was years ago - I'm a bit flabbergasted I remember the rough course outlines relatively well).

* Being able to dump the unpacked binary program from memory onto disk. Understanding page alignment was rough. Because even if you got it, there were a few gotcha's. I've looked at so many hexdumps it was insane.

* Taint analysis: watching user input "taint" other variables

* Instrumenting a binary with Intel PIN

* Cracking some program with Triton. I think Triton helped to instrument your binary with the help of Intel PIN by putting certain things (like xor's) into an SMT equation or something and you had this SMT/Z3 solver thingy and then you cracked it. I don't remember got a 6 out of 10 for this assignment, had a hard time cracking the real thing.

Computer & Network Security:

* Web securtiy: think XSS, CSRF, SQLi and reflected SQLi

* Application security: see binary and malware analysis

* Network security: we had to create our own packet sniffer and we enacted a Kevin Mitnick attack (it's an old school one) where we had to spoof our IP addresses, figure out the algorithm to create TCP packet numbers - all in the blind without feedback. Kevin in '97 I believe attacked the San Diego super computer (might be wrong about the details here). He noticed that the super computer S trusted a specific computer T. So the assignment was to spoof the address of T and pretend we were sending packets from that location. I think... writing this packet sniffer was my first C program. My prof. thought I was crazy that this was my first time writing C. I was, I also had 80 hours of time and motivation per week. So that helped.

* Finding vulnerabilities in C programs. I remember: stack overflows, heap overflows and format strings bugs.

-----

For binary & malware analsys + computer & network security I highly recommend hackthebox.eu

For hardware security, I haven't seen an alternative. To be fair, I'm not looking. I like to dive deep into security for a few months out of the year and then I can't stand it for a while.

markus_zhang18 days ago

Wow, thanks a lot for the detailed answer. I'm going to see if I can register as a contracted student, but they probably do not accept remote students.

BTW I can see you were very motivated back then. It got to be pretty steep but you managed to break through. Congrats!

mettamage18 days ago

Remote won't work yea. It has to be in-person.

> BTW I can see you were very motivated back then. It got to be pretty steep but you managed to break through. Congrats!

Thanks! Yea I was :)

rakingleaves18 days ago

Anyone know how this relates to the Training Solo attack that was just disclosed? https://www.vusec.net/projects/training-solo/

hashstring18 days ago

Both exploit Spectre V2, but in different ways. My takeaway:

Training Solo: - Enter the kernel (and switch privilege level) and “self train” to mispredict branches to a disclosure gadget, leak memory.

Branch predictor race conditions: - Enter the kernel while your trained branch predictor updates are still in flight, causing the updates to be associated with the wrong privilege level. Again, use this to redirect a branch in the kernel to a disclosure gadget, leak memory.

rini1718 days ago

If CPU brach predictor had bits of information readily available to check buffer boundaries and privilege level of the code, all this would be much easier to prevent. But apparently that will only happen when we pry out the void* from the cold C programmers' hands and start enriching our pointers with vital information.

ajross18 days ago

I don't see how you think that will help? It's not about software abstraction, it's about hardware. Changing the "pointer" does nothing to the transistors.

Doing what you want would essentially require a hardware architecture where every load/store has to go through some kind of "augmented address" that stores boundary information.

Which is to say, you're asking for 80286 segmentation. We had that, it didn't do what you wanted. And the reason is that those segment descriptors need to be loaded by software that doesn't mess things up. And it doesn't, it's "just a pointer" to software and amenable to the same mistakes.

nine_k18 days ago

Why stop at 80286, consider going back to the ideas of iAPX432, but with modern silicon tech and the ability to spend a few million transistors here and there.

(CHERI already exists on ARM and RISC-V though.)

ajross18 days ago

FWIW, the 286 launched like four months after the 432.

rini1718 days ago

286 far pointers were used sparingly, to save precious memory. Now we don't have any such problem and there are still unused bits in pointers even on largest 64 bit systems that might be repurposed perhaps. With virtual memory, there are all kinds of hardware supported address mappings and translations and IOMMU already so adding more transistors isn't an issue. The issue is purely cultural as you have just shown, people can't imagine it.

ajross18 days ago

That's misunderstanding the hardware. All memory access on a 286 was through a segment descriptor, every access done in protected mode was checked against the segment limit. Every single one.

A "far pointer" was, again, a *software* concept where you could tell the compiler that this particular pointer needed to use a different descriptor than the one the toolchain assumed (by convention!) was loaded in DS or SS.

nottorp18 days ago

I suppose a CPU that only runs Rust p-code is what the OP is dreaming about...

ajross18 days ago

Generated rust "p-code" would presumably be isomorphic to LLVM IR, which doesn't have this behavior either and would be subject to the same exploits.

Again, it's just not a software problem. In the real world we have hardware that exposes "memory" to running instructions as a linear array of numbers with sequential addresses. As long as that's how it works, you can demand an out of bounds address (because the "bounds" are a semantic thing and not a hardware thing).

It is possible to change that basic design principle (again, x86 segmentation being a good example), but it's a whole lot more involved than just "Rust Will Fix All The Things".

nottorp18 days ago

Holy... I need to stop making fun of Rust (*). I keep getting misinterpreted.

(*) ... although I don't think I can abstain ...

quotemstr18 days ago

You want CHERI.

ActorNightly18 days ago

Or people could just understand the scope of the issue better, and realize that just because something has a vulnerability doesn't mean there is a direct line to an attack.

In the case of speculative execution, you need an insane amount of prep to use that exploit to actually do something. The only real way this could ever be used is if you have direct access to the computer where you can run low level code. Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets.

And in the case of systems that are valuable enough to exploit with a risk of a dedicated private or state funded group doing the necessary research and targeting, there should be a system that doesn't allow unauthorized arbitrary code to run in the first place.

I personally disable all the mitigations because performance boost is actually noticeable.

vlovich12318 days ago

> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets

That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack.

> I personally disable all the mitigations because performance boost is actually noticeable.

Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.

nine_k18 days ago

Disabling some mitigations makes sense for an internal box that does not run arbitrary code from the internet, like a build server, or a load balancer, or maybe even a stateless API-serving box, as long as it's not a VM on a physical machine shared with other tenants.

+3
anyfoo18 days ago
ActorNightly17 days ago

>Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.

No wonder you guys are scared AI is going to take your job lol.

Thats not how it works at all. To grab a key stored in a JS variable, the following would need to happen

1. Attacker needs to find a way to inject arbitrary JS code in a website, which means controlling either an iframe that is loaded or some component. This is a pretty hard thing to do these days with Same-Site strictness

2. The code needs to know specifically what memory address to target. When things like JWT or other tokens are stored in session or local storage, the variable name usually contains a random string. Injected code will have to figure out a way to find what that variable name is.

3. For attack to work, the cache has to get evicted. This is highly processor specific on how well it works, and also, the web app has to be in a state where no other process is referencing that variable. With JS, you also have to infer memory layout (https://security.googleblog.com/2021/03/a-spectre-proof-of-c...) first, which takes time. Then you have to train the branch predictor, which also takes time.

So basically, I have a statistically higher chance of losing my keys to someone who physically robs me rather than a cache timing attack.

Generally when an exploit like this drops, people always have failures to update their systems, and you see it being used in the wild. With Spectre/Meltdown, this didn't really happen, because of the nature of how these attacks work and the difficulty of getting the cache timing code to work correctly without specific targeting of a processor and ability to execute arbitrary code on the machine.

+1
anyfoo17 days ago
gblargg18 days ago

Who these days would trust crypto keys on their machine, given the many hardware wallets available?

vlovich12318 days ago

Where do you think the crypto keys for the TLS connection securing your HTTPS browsing are stored? Although from what you said I’m now thinking you’re referring to cryptocurrency & thus aren’t on the same wavelength of the discussion here. Crypto keys —> cryptography keys, not cryptocurrency keys.

ActorNightly17 days ago

I think he means crypto as in like tokens, not wallet keys.

anyfoo18 days ago

> Or people could just understand the scope of the issue better

Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet (so, not targeted, but spread out, think opportunistic ransomware) attack?

Because this statement of yours:

> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets.

was not true for Spectre. The original spectre paper notoriously mentions JS as an attack vector.

If you truly disable all mitigations (assuming CPU and OS allow you to do so), you will reopen that hole.

So:

> The only real way this could ever be used is if you have direct access to the computer where you can run low level code.

I'm a low level kernel engineer, and I don't know this to be true in the general case. JITs, i.e. the JavaScript ones, also generate "low level code". How do you know of this not being sufficient?

ActorNightly17 days ago

>Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet

The issue is not whether or not it could affect me, the issue is what is the risk. And I can say for certain that the risk is very low, because I seem to have more understanding of the space.

>The original spectre paper notoriously mentions JS as an attack vector.

In an analogy, having an attack vector is having a certain type of weapon, while executing a full exploit end to end is on the scope of waging a war. Sure, a right person at the right place with that weapon can take out a critical target and win the war, but just having that weapon doesn't guarantee you winning a war.

In the cases of certain exploits, like Log4Shell, thats like having a portable shotgun that shoots hypersonic missiles in a scatter pattern. Log4Shell basically means that if anything gets logged, even an error message, that can be used to execute arbitrary code, and its super easy to check if this is the case - send payloads to all services with a JNI url that you control and see what pops up, and boom, you can have shells on those computers.

In the case of Spectre/Meltdown, its like having a specific type of booby trap. Whether or not you can actually set up that booby trap highly depends on environment. If a website is fully protected against code injection, then executing JS cache timing would be impossible. And even if it wasn't, there would be other

Of course nothing is ever for certain. For example, browsers can contain some crazy logic bug that bypasses Same-Origin checks that nobody has found yet. But the chance of this happening is extremely low, as browser code is public.

+1
anyfoo17 days ago
layer818 days ago
rtkwe18 days ago

I wonder if there's similar gaps in AMD hardware? Seems like speculative execution is simply an extremely hard to patch vulnerability in a share processor space so I wonder how AMD has avoided it.

tmoertel18 days ago

According to the authors' blog post:

> Does Branch Privilege Injection affect non-Intel CPUs?

> No. Our analysis has not found any issues on the evaluated AMD and ARM systems.

Source: https://comsec.ethz.ch/research/microarch/branch-privilege-i...

__turbobrew__18 days ago

Intel is getting kicked while it is down.

pdpi18 days ago

The short of it is that AMD haven’t “avoided it”. Speculative execution side channels aren’t one vulnerability but rather a whole family of vulnerabilities. This particular one is (apparently) Intel-only, same as Meltdown was, but AMD was also vulnerable to the original Spectre.

bee_rider18 days ago

Pedantically, speculative execution isn’t the vulnerability, it is a necessary mechanism for every high-performance CPU nowadays (where “nowadays” started, like, around the turn of the century). However, bugs and vulnerabilities in speculative execution engines are very widespread because they are complicated.

There are probably similar bugs in AMD and ARM, I mean how long did these bugs sit undiscovered in Intel, right?

Unfortunately the only real fix is to recognize that you can’t isolate code running on a modern system, which would be devastating to some really rich companies’ business models.

fc417fc80218 days ago

> the only real fix is to recognize that you can’t isolate code running on a modern system

Does pinning VMs to hardware cores (including any SMT'd multiples) fix this particular instance? My understanding was that doing that addressed many of the modern side channel exploits.

Of course that's not ideal, but it's not too bad in an era where the core count of high end CPUs continues to creep upwards.

vlovich12318 days ago

If this allows reading kernel memory, then your VMs could read the host kernel anyway & any security keys contained therein (& that’s assuming pinning cores limits the exploit to memory being accessed by other CPUs on the same core which generally has not been true of side channel attacks as far as I’m aware).

everfrustrated18 days ago

Possibly not. Seems like this exploit allows walking memory which would be shared?

fc417fc80217 days ago

But can you exfiltrate memory without it being accessed on the core you're running on? I thought branch predictors were a one-per-physical-core sort of thing and that this class of side channel attack leaked something being done on the same core in a different privilege domain.

rtkwe17 days ago

I meant that it's a feature that's hard to implement in a way that delivers the performance gains without creating vulnerabilities like this one.

quotemstr18 days ago

The solution to this particular vulnerability is intuitive to me: snapshot the current privilege level when we enqueue a branch predictor update and carry that snapshot along with the update itself as it flows through the processor's internal buffers. Same problem you might have in software and the same solution, yes?

wbl18 days ago

That actually doesn't work. The evaluation of the branch condition may be at some point far away from where the privilege update is recognized and executed. There is no current state to update, it's only recognized in retrospect what the state was. And carrying along data is pricey in a CPU: the instruction pointer isn't even available because of this.

You could say we only update the predictor at retirement to solve this. But that can get a little dicy also: the retirement queue would have to track this locally and retirement frees up registers, better be sure it's not the one your jump needs to read. Doable but slightly harder than you might think.

smartmic18 days ago

> Closing these sorts of gaps requires a special update to the processor’s microcode. This can be done via a BIOS or operating system update and should therefore be installed on our PCs in one of the latest cumulative updates from Windows.

Why mention only Windows, what about Linux users?

ajross18 days ago

Intel distributes microcode updates for Linux here: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... , and the distro are all set up to pull from there and distribute automatically.

Not expert enough to know what to look for to see if these particular mitigations are present yet.

yencabulator17 days ago

Researchers say this is CVE-2024-45332.

INTEL-SA-01247 covers that CVE.

Microcode release 20250512 has that INTEL-SA mitigated.

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://www.intel.com/content/www/us/en/security-center/advi...

brokenmachine18 days ago

On an Ubuntu 24.04.2 machine:

   dpkg -l | grep microcode

   ii  amd64-microcode 3.20231019.1ubuntu2.1 amd64 Processor microcode firmware for AMD CPUs
   ii  intel-microcode 3.20250211.0ubuntu0.24.04.1 amd64 Processor microcode firmware for Intel CPUs
   ii  iucode-tool 2.3.1-3build1 amd64 Intel processor microcode tool
matja18 days ago

The Linux kernel has had microcode loading support (`CONFIG_MICROCODE` / `CONFIG_MICROCODE_INTEL`) but many years, but it does require that Intel release the microcode files necessary for distribution maintainers to update the packages, then it should be included in a system update.

margorczynski18 days ago

I wonder if there's any way to recover for Intel. They don't have anything worthwhile on the market, R&D takes a lot of time and their foundries are a constant source of losses as they're inferior compared to the competition.

On top of that x86 seems to be pushed out more and more by ARM hardware and now increasingly RISC-V from China. But of course there's the US chip angle - will the US, especially after the problems during Covid, let a key manufacturer like Intel bite the dust?

chneu18 days ago

Intel really isn't in as much trouble as tech blogs like to act.

It's not great but lol the sensationalism is hilarious.

Remember, gamers only make up a few percentage of users for what Intel makes. But that's what you hear about the most. One or two data center orders are larger than all the gaming cpus Intel will sell in a year. And Intel is still doing fine in the data center market.

Add in that Intel still dominates the business laptop market which is, again, larger than the gamer market by a pretty wide margin.

WaxProlix18 days ago

You're right about gamers, but other verticals are looking bad for Intel, too.

The two areas you mention (data center, integrated OEM/mobile) are the two that are most supply chain and business-lead dependent. They center around reliable deliveries of capable products at scale, hardware certifications, IT department training, and organizational bureaucracy that Intel has had captured for a long time.

But!

Data center specifically is getting hit hard from AMD in the x86 world and ARM on the other side. AWS's move to Graviton alone represents a massive dip in Intel market share, and it's not the only game in town.

Apple is continuing to succeed in the professional workspace, and AMD's share of laptop and OEM contracts just keeps going up. Once an IT department or their chosen vendor has retooled to support non-Intel, that toothpaste is not going back into the tube - not fully, at least.

For both of these, AMD's improvement in reliability and delivery at scale will be bearing fruit for the next decade (at Intel's expense), and the mindshare, which gamers and tech sensationalism are indicators for, has already shifted the market away from an Intel-dominated world to a much more competitive one. Intel will have to truly compete in that market. Intel has stayed competitive in a price-to-performance sense by undermining their own bottom line, but that lever only has so far it can be pulled.

So I'm not super bullish on Intel, sensationalism aside. They have a ton of momentum, but will need to make use of it ASAP, and they haven't shown an ability to do that so far.

layer818 days ago

Intel still has well over 70% x86 market share. They have a long runway. Arm had only 15% datacenter market share last year, and still hasn’t made much headway in the Windows market.

drob51817 days ago

The trend toward ARM in both laptops and data centers is clear. It’s being driven by power efficiency as much as performance. The x86 guys have shown that they can make x86 fast and that CISC is really not an issue, but that takes a lot of transistors and those transistors inevitably burn power. For the same performance, x86 will always be more power hungry. And so the industry will keep moving toward ARM and RISC-V.

freeone300018 days ago

Arm is making huge gains though — five years ago they had less than 5%. The future of x86 is not bright.

baq18 days ago

x86 vs arm doesn’t matter. Hardware matters. Intel needs to make the best cpu again. It can be x86, it can be arm, it can be risc-v.

+1
adgjlsfhk118 days ago
porridgeraisin18 days ago

I guess it depends on your expectations. Will they be fine as a company? I think yes. Will they be as prominent as they were at different points in their history? I think not.

Product aside, from a shareholder/business point of view (I like to think of this separately these days as financial performance is becoming less and less reflective of the end product) I think they are too big to fail.

emkoemko18 days ago

didn't i read something about apple,nvidia and other companies looking to use their foundries? why would they do that if its inferior or was that something else?

greenavocado18 days ago

Because there's nothing else in America

yonatan807018 days ago

Just to make sure I got this right, at this point in time there are patches out for all major operating systems that can mitigate this/apply relevant microcode to mitigate it?

dboreham18 days ago

Yes. Embargo date May 13 (today).

HeliumHydride18 days ago

https://scholar.harvard.edu/files/mickens/files/theslowwinte...

"Unfortunately for John, the branches made a pact with Satan and quantum mechanics [...] In exchange for their last remaining bits of entropy, the branches cast evil spells on future generations of processors. Those evil spells had names like “scaling-induced voltage leaks” and “increasing levels of waste heat” [...] the branches, those vanquished foes from long ago, would have the last laugh."

Hackbraten18 days ago

I love James Mickens!

https://www.usenix.org/system/files/1401_08-12_mickens.pdf

> The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, […] they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.

wood_spirit18 days ago

So this is where they got the pager and walkie talkie ideas from

genewitch18 days ago

You know, I didn't really think of this till your comment: this was a vast conspiracy spanning years. You always hear, when discussions of "conspiracies" happen, things like "it would involve too many people, too many moving parts" like opsec would be impossible. And then you have the pagers.

Kinda like the old chestnut that rich people are only rich on paper and then, Musk buys twitter. Not tesla, or some DBA, Musk.

This decade might actually be the season of reveal.

angra_mainyu18 days ago

I think this is a human thing, being very myopic given our short lifespans, we forget even relatively recent things.

The Cold War for example was full of these intricate, complex and stunning feats of spycraft that they'd pull off on each other.

btown18 days ago

This is absolute gold!

> “Making processors faster is increasingly difficult,” John thought, “but maybe people won’t notice if I give them more processors.” This, of course, was a variant of the notorious Zubotov Gambit, named after the Soviet-era car manufacturer who abandoned its attempts to make its cars not explode, and instead offered customers two Zubotovs for the price of one, under the assumption that having two occasionally combustible items will distract you from the fact that both items are still occasionally combustible.

> Formerly the life of the party, John now resembled the scraggly, one-eyed wizard in a fantasy novel who constantly warns the protagonist about the variety of things that can lead to monocular bescragglement.

And in 2013 the below would have been correct, but we live in a very different world now:

> John’s massive parallelism strategy assumed that lay people use their computers to simulate hurricanes, decode monkey genomes, and otherwise multiply vast, unfathomably dimensioned matrices in a desperate attempt to unlock eigenvectors whose desolate grandeur could only be imagined by Edgar Allen Poe. Of course, lay people do not actually spend their time trying to invert massive hash values while rendering nine copies of the Avatar planet in 1080p.

He wasn't too far off about the monkeys, though...

bee_rider18 days ago

The bit about vast matrices shows some silver lining though; it turns out John’s little brother figured out how to teach those matrices to talk like a person.

yvdriess18 days ago

Yes but those transistors moved to greener pastures.

20198418 days ago

  mitigations=off
Don't care.
matja18 days ago

"Don't mind me running this piece of WASM in a webworker to collect all the useful encryption keys and cookies in your RAM..."

20198418 days ago

Has even a single web exploit ever been found in the wild? Until then, I'm not going to worry and probably not even then.

dzaima18 days ago

As long as most people run with mitigations on, you're technically probably indeed safe. But you should still care that things get fixed with mitigations=on otherwise you wouldn't have the shield of "almost everyone has mitigations enabled for this so noone has reason to bother exploiting this"!

autoexec18 days ago

Yes, at least in the Spectre/Meltdown days. https://www.techtarget.com/searchsecurity/news/252434342/Mel...

teruakohatu18 days ago

Haven’t browsers closed that hole independently by reducing timing precision?

johnnyjeans18 days ago

Uncaught ReferenceError: WebAssembly is not defined

vlovich12318 days ago

You don't need WASM to deploy Spectre/Meltdown. Vanilla JS works just fine which is what was demonstrated in the original paper.

+2
brobinson18 days ago
anthk18 days ago

UBlock Origin with JS turned off, or NoScript. Good luck.

bee_rider18 days ago

Yeah, he should really turn mitigations on, so that when running arbitrary code from the internet he can be subject to 9999 vulnerabilities, instead of 10,000.

darkmighty18 days ago

There are many kinds of vulnerabilities. Most are pretty mundane afaict. Breaking sandboxes and reading out your entire RAM is basically game over, existential vulnerability (second only to arbitrary code execution, though it can give you SSH keys I guess).

The mitigating factor is actually that you don't go to malicious websites all the time, hopefully. But it happens, including with injected code on ads and stuff that may enabled by secondary vulnerabilities.

anyfoo18 days ago

I challenge you to name another readily available "read arbitrary RAM from userspace"[1] vulnerability.

[1] Not even including "potentially exploitable from JavaScript", which Spectre was. It's sufficient if you name one where an ordinary userspace program can do it.

+2
genewitch18 days ago
tannhaeuser18 days ago

> All intel processors since the 9th generation (Coffee Lake Refresh) are affected by Branch Privilege Injection. However, we have observed predictions bypassing the Indirect Branch Prediction Barrier (IBPB) on processors as far back as 7th generation (Kaby Lake).

From that piece of text on the blog, I don‘t quite unterstand if Kaby Lake CPUs are affected or not.

fwip18 days ago

At least some Kaby Lake CPUs are affected, but they can't say for sure that all of them are.

lostmsu18 days ago

No, I think they are saying that they can only demonstrate exploit on Coffee Lake Refresh and later, but the issue that let them create exploit exists all the way back to Kaby Lake. So they are also probably exploitable, but this specific exploit does not target them.

chrisweekly18 days ago

I interpret it as including Kaby Lake.

autoexec18 days ago

which would mean that all our intel machines have been vulnerable and defenseless for the last 9 years.

Alcatros55218 days ago

As it seems a lot of people are not aware that this one is a newer generation of branch predictor issue. You can see that Intels eIBRS doesn't mitigate the problems and make them susceptible to attacks. To prevent bigger issues the issue was released after Intel has been informed of the Issue and most systems are patched in the meantime.

dzdt18 days ago

The end-user processor slowdowns from Spectre and Meltdown mitigations were fairly substantial. Has anyone seen an estimate of how much the microcode updates for this new speculative vulnerability are going to cost in terms of slowdown?

leonidasv18 days ago

> Our performance evaluation shows up to 2.7% overhead for the microcode mitigation on Alder Lake. We have also evaluated several potential alternative mitigation strategies in software with overheads between 1.6% (Coffee Lake Refresh) and 8.3% (Rocket lake)

https://comsec.ethz.ch/research/microarch/branch-privilege-i...

dzdt18 days ago

Thanks, missed that! I remember seeing benchmarks showing like 15% slowdown from Spectre/Meltdown mitigations, so this is not as bad as that, but that is on top of the other too I guess...

j4518 days ago

Since the cloud is someone else's computer, and someone else's shared CPU, is cloud hosting (including vps) potentially impacted?

Look forward to learning how this can be meaningfully mitigated.

andrewla18 days ago

Intel claims [1] that they already have microcode mitigation. Like Spectre and Meltdown this is likely to have performance implications.

[1] https://www.intel.com/content/www/us/en/security-center/advi...

j4518 days ago

Spectre and Meltdown had some pretty big performance hits in the beginning. Wonder how much it will differ here in real world, third party (and independent) testing.

matja18 days ago

For reads across different VMs on the same CPU, theoretically TME-MK could mitigate the usefulness of the memory reads by having each VM access memory using a different memory encryption key, but I don't know of any hypervisors that implement this.

AMD has had SEV support in QEMU for a long time, which some cloud hosting providers use already, that would mitigate any such issue if it occurred on AMD EPYC processors.

wahern18 days ago

Memory encryption doesn't usually protect against these kinds of side channels. You're not reading memory directly, but inferring it based on discernible behavior of the privileged code. Inasmuch as SEV and TME-MK are marketed as protecting VM guest memory from host machine snooping, they've proven insufficient many times before.[1] In the end, you have to trust your VM hosting provider, and trust that they've written their hypervisors in a robust way that takes into account these unforeseen (yet predictable) issues when isolating guests from each other.

[1] See, e.g., https://www.amd.com/en/resources/product-security/bulletin/a... and https://www.intel.com/content/www/us/en/developer/articles/t...

anonymousDan18 days ago

Memory encryption typically doesn't keep anything encrypted within the CPU (e.g. in caches). Haven't looked at the details of this bug but I expect it wouldn't help for that reason.

j4518 days ago

Appreciate the insight on the AMD side.

Their new processors are quite inviting, but like with all CPU’s I’d prefer to keep the entire thing to myself.

The28thDuck18 days ago

Haven’t we been here before? It seems like it’s very similar to the branch prediction exploits of the late 2010s. Is there something particularly novel about this class of exploits?

mettamage18 days ago

Probably, I haven't had time to delve into the article yet. But ever I first learned about them I got the hunch that they'd never fully go away.

Then people say "no that's not possible, we got security in place."

So then the researchers showcase a new demo where they use their existing knowledge with the same issue (i.e. scaling-induced voltage leaks).

I suspect this will go on and on for decades to come.

dboreham18 days ago

It's the same exploit, just exploiting a bug in the mitigation for the first exploit.

LkpPo10 days ago

Predictable suite.^_^ Disable the feature in BIOS if possible. Branch prediction is a rotten plank that needs to be scrapped. It's a remarkably bad idea that doesn't deserve to be saved.

x3al17 days ago

Is there an easy way to run a browser on some phone/tablet and everything else on a desktop just to isolate the web and JS from accessing your desktop?

pawanjswal18 days ago

Just when we thought Spectre was fading, it pulls a full sequel—Intel CPUs still keeping things spicy!

arkh18 days ago

So is it time for some cryptography coprocessor / cards?

gitroom18 days ago

yeah this just makes me wanna see real world numbers on the slowdown, cuz honestly all these microcode fixes feel like trading off years of speed for maybe a little more peace of mind - you ever think well actually move off this cycle or is it just here to stay?

myself24817 days ago

I'd love to see a graph showing mitigations=off vs mitigations=on speed gains over the years. It feels like most of the new tricks have had vulnerabilities of some sort, which eat up some or most of their gains.

Of course at launch, the vulns haven't been found yet, so the performance uplift claims are all fluff based on the reckless actions of an unprotected trick. By the time the skeletons have come out of the closet, the release hype cycle is far in the past, and only a few nerd blogs will cover the corresponding performance hit.

Lather, rinse, repeat for the next launch. New tricks, new reckless performance gains, big uplift numbers, hope it takes a little while before anybody points out the holes in the emperor's clothes. But at the end of the day, the actual performance progress over time is, I suspect, dramatically slower than what the naïve summation of individual launch-day claims would suggest.

To your second point:

I think it's here to stay as long as we allow someone else's code (via js, webassembly, and their ilk) to run on our processors as a matter of course.

A rethink of the entire modern web, back to a simpler markup language that isn't Turing-complete and can't leak data back to the attacker's server, would be needed before we could turn the mitigations off and enjoy the performance we were promised.

But of course, if we get rid of the modern web as we know it, we probably don't need all that performance anyway. An old BlueWave/QWK mailer consumes 10,000x less resources than a Gmail tab, you know?

unit14918 days ago

[dead]

whatever118 days ago

It’s dead, can you please stop stubbing it?

anonymars18 days ago

I thought I understand these words, yet I don't understand what you mean

arghwhat18 days ago

> On an up to date Ubuntu 24.04

So not very up to date, but I suppose mitigations haven't changed significantly upstream since then.

necubi18 days ago

24.04 is the most recent LTS (long term support) release; it's what users are meant to be running for anything important

arghwhat18 days ago

My point is that it is not representative of the current state of the kernel.

The kernel has nothing to do with Ubuntu, its release schedule and LTS's. Distro LTS releases also often mean custom kernels, backports, hardware enablement, whatnot, which makes it a fork, so unless were analyzing Ubuntu security rather than Linux security, mainline should be used.

42lux18 days ago

Microcode updates have nothing to do with the kernel?

arghwhat18 days ago

Mitigations are generally kernel workarounds, not microcode updates. Microcode updates provide some fixes or disable features, but all kernel efforts and why they specify the software at all is because of kernel mitigations.

dboreham18 days ago

Correct.

FirmwareBurner18 days ago

[flagged]

thomasdziedzic18 days ago

That version is significant because it is the latest LTS release. Most servers use LTS releases.

7bit18 days ago

There is a difference between an up2date Ubuntu 24.04 and an up2date Ubuntu.

And as security updates are back ported to all supported versions - and 24.04 being an LTS release, it is as up2date as it gets.

If you're being pedantic, be the right kind of pedantic ;)

arghwhat18 days ago

The problem is that it's downstream backports and hardware enablement - you're running an old forked artisinal kernel maintained by Canonical, you will only get bugfixes if known to be severe enough to be flagged, and all this patching deviates it from mainline and can itself introduce new security vulnerabilities not present in mainline.

This differs from an actual later release which is closer to mainline and includes all newer fixes, including ones that are important but weren't flagged, and with less risk of having new downstream bugs.

If you're going to fight pedantism by being pedantic, better be the right kind of pedantic. ;)

blueflow18 days ago

Ubuntu 24.04 is the current LTS release. Our are you intending to say that Ubuntu, regardless of version, is not up to date?

Edit: "LTS" added due to popular demand

pdpi18 days ago

You need a qualifier there — the latest Ubuntu release is 25.04, but 24.04 is the current LTS release.

razemio18 days ago

It is up to date, with security patches and fixes. That is obviously what is relevant here. That is why the parent comment got down voted, since it is up to date in context of a security vulnerability. It should be even more secure, since new software versions might introduce unknown attack vectors.

arghwhat18 days ago

I am saying that any version of Ubuntu is not representative of the mainline kernel, which is what is relevant when it comes to analyzing current mitigations.

Distro LTS releases often mean custom kernels, backports, hardware enablement, whatnot, which makes it effectively a fork.

Unless were interested in discovering kernel variation discrepancies, its more interesting to analyze mainline.

fc417fc80218 days ago

I'd expect an awful lot of production workloads to be running on LTS kernel versions (and likely also LTS distro releases). So the mitigations currently available in an LTS release of a mainstream distro are quite relevant.

arghwhat18 days ago

They are running their LTS distro's LTS kernel, but that us not an upstream thing

On an LTS, you'll be running a Canonical kernel, or a Red Hat kernel, or a SuSE kernel, or an Oracle kernel, or...

Each will have different backports, different hardware enablement, different random patches of choice, and so different bugs and problems.

Unless were evaluating the security of a particular distro release, mainline is what is Linux and will ultimately be the shared base for future releases.

fwip18 days ago

24.04 is an LTS (long term support) release, so it receives updates, including security updates, for much longer than a regular release. I believe it's a 5-year support window, and longer if you shell out for paid support.

arghwhat18 days ago

These updates mean that you are no longer running a mainline kernel, but an Ubuntu fork with whatever backports and hardware enablement (and new bugs!) this might introduce. This is also true for other software.

LTS does not mean you get all updates, it only means you get to drag your feet for longer with random bugfixes. Only the latest release has updates.

anyfoo18 days ago

This only matters if the mainline kernel since then somehow experienced changes which would affect this hardware vulnerability (fixed through microcode), which I see no indication of?

+1
arghwhat18 days ago