> [...] 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_proven · 3h ago
Prepare for another dive maneuver in the benchmarks department I guess.
cenamus · 3h ago
And if not, why did they introduce severe bugs for a tiny performance improvement?
bloppe · 2h ago
It's not tiny. Speculative execution usually makes code run 10-50% faster, depending on how many branches there are
bee_rider · 2h ago
Yeah… folks who think this is just some easy to avoid thing should go look around and find the processor without branch prediction that they want to use.
On the bright side, they will get to enjoy a much better music scene, because they’ll be visiting the 90’s.
trebligdivad · 2h ago
Thanks! It would be great if someone could update the title URL to that blog post; the press release is worse than useless.
"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."
> 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_spirit · 26m ago
So this is where they got the pager and walkie talkie ideas from
bee_rider · 1h 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.
mettamage · 3h 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_zhang · 2h 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?
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.
ActorNightly · 47m 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.
vlovich123 · 15m 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.
quotemstr · 1h ago
You want CHERI.
ajross · 2h 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.
rini17 · 39m 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.
ajross · 6m 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.
nine_k · 1h 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.)
nottorp · 2h ago
I suppose a CPU that only runs Rust p-code is what the OP is dreaming about...
ajross · 2h 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".
nottorp · 2h ago
Holy... I need to stop making fun of Rust (*). I keep getting misinterpreted.
(*) ... although I don't think I can abstain ...
smartmic · 2h 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?
matja · 2h 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.
Not expert enough to know what to look for to see if these particular mitigations are present yet.
rtkwe · 3h 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.
tmoertel · 3h 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.
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_rider · 2h 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.
quotemstr · 1h 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?
yonatan8070 · 2h 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?
gitroom · 26m 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?
201984 · 2h ago
mitigations=off
Don't care.
matja · 1h 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..."
bee_rider · 59m 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.
darkmighty · 29m 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.
johnnyjeans · 1h ago
Uncaught ReferenceError: WebAssembly is not defined
vlovich123 · 13m ago
You don't need WASM to deploy Spectre/Meltdown. Vanilla JS works just fine which is what was demonstrated in the original paper.
dzdt · 2h 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?
leonidasv · 2h 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)
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...
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?
chneu · 2h 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.
WaxProlix · 2h 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.
layer8 · 2h 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.
freeone3000 · 2h ago
Arm is making huge gains though — five years ago they had less than 5%. The future of x86 is not bright.
baq · 1h 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.
adgjlsfhk1 · 33m ago
Arm vs x86 matters a lot for Intel since they don't make Arm CPUs. x86 used to be a massive moat for Intel/AMD. The rise of ARM market-share means that that moat is draining. 10 years ago, AMD and IBM were the only competition (and they were both in rough shape). Now Intel is competing against AMD, NVidia, Qualcom, Amazon, and Arm. Even if Intel can make the best CPU again, they no longer can charge monopoly prices for it. If you have a 10% faster CPU, that only lets you charge a small premium over everyone else.
emkoemko · 2h 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?
greenavocado · 2h ago
Because there's nothing else in America
porridgeraisin · 2h 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.
tannhaeuser · 2h 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.
chrisweekly · 2h ago
I interpret it as including Kaby Lake.
fwip · 1h ago
At least some Kaby Lake CPUs are affected, but they can't say for sure that all of them are.
j45 · 2h 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.
matja · 1h 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.
andrewla · 2h ago
Intel claims [1] that they already have microcode mitigation. Like Spectre and Meltdown this is likely to have performance implications.
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.
whatever1 · 3h ago
It’s dead, can you please stop stubbing it?
anonymars · 2h ago
I thought I understand these words, yet I don't understand what you mean
arghwhat · 3h 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.
necubi · 3h ago
24.04 is the most recent LTS (long term support) release; it's what users are meant to be running for anything important
FirmwareBurner · 2h ago
>it's what users are meant to be running for anything important
Anything important requires TempleOS.
thomasdziedzic · 3h ago
That version is significant because it is the latest LTS release. Most servers use LTS releases.
blueflow · 3h 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
pdpi · 3h ago
You need a qualifier there — the latest Ubuntu release is 25.04, but 24.04 is the current LTS release.
razemio · 2h 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.
7bit · 3h 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 ;)
fwip · 3h 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.
Paper: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
> [...] 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.
On the bright side, they will get to enjoy a much better music scene, because they’ll be visiting the 90’s.
"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."
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.
Do you know if there is any official recording or notes online?
Thanks in advance.
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.
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.
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.
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.
(CHERI already exists on ARM and RISC-V though.)
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".
(*) ... although I don't think I can abstain ...
Why mention only Windows, what about Linux users?
Not expert enough to know what to look for to see if these particular mitigations are present yet.
> 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...
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.
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.
https://comsec.ethz.ch/research/microarch/branch-privilege-i...
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?
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.
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.
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.
From that piece of text on the blog, I don‘t quite unterstand if Kaby Lake CPUs are affected or not.
Look forward to learning how this can be meaningfully mitigated.
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.
[1] https://www.intel.com/content/www/us/en/security-center/advi...
So not very up to date, but I suppose mitigations haven't changed significantly upstream since then.
Anything important requires TempleOS.
Edit: "LTS" added due to popular demand
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 ;)