That’s because of monopolies… There are only two brands of PC CPUs you could own…

That’s a very bad idea.

The bad news is that the exploit doesn’t require physical hardware access and can be triggered by loading JavaScript on a malicious website.

It’s worth noting these are the firmware / microcode fixes.

There’s already a software solution available,

There is a software workaround, you can set the chicken bit DE_CFG[9]. This may have some performance cost, and the microcode update is preferred.

source: https://www.openwall.com/lists/oss-security/2023/07/24/3

AMD has also already released a fix for the big boy - the EPYC processor.

It wasn’t branch prediction alone, it was the cache combined with branch prediction. The problem is that even discarded outcomes fill the cache with data. Those older vulnerabilities also had the problem that the access permissions check was done after the branch prediction. It’s probably too expensive to do when it’s not even clear yet whether the branch is going to be taken (that’s just speculation on my part though).

The more steps in the instruction pipeline the more ways there are for there to be an error where some result doesn’t get erased when undoing stuff from the wrong branch. It’s basically like telling someone to move into a new house and get settled then stopping them six hours in and trying to make sure you get all their stuff out.

They’ve had a couple. Spectre is the one to which you’re referring, I bet.

So far the word is the microcode fix causes negligible performance impact, but using the MSR fix causes 5-15% loss. In my own testing on EPYC hardware, microcode made no noticable difference to my workloads and benchmarks. Same as random noise in results.

A CPU performs operations like “read a small bit of thing from the memory into the CPU” and “do a small bit of computation on things inside the CPU” and “put a small bit of thing from the CPU into the memory”.

Doing small bits of computation on things inside the CPU is very fast but moving bits of things from or to the memory is slow in comparison. In order to not be slowed down, CPUs read the code ahead of what is currently being executed, and try to guess what is going to happen and what will need to be moved from the memory into the CPU, so they can do it ahead of time, and have the small bit of thing from the memory already available right there in the CPU when it’s time to do a bit of computation on it. That way, there is no need to wait on slow memory, and the CPU runs much faster overall. That’s a good thing.

In this case, a researcher found a way to make certain CPUs guess what is going to happen with the code wrong, in such a way that the small bits of things that were read from the memory ahead of time do not get properly cleaned up, and can still be found inside the CPU by another program. Those small bits of things might be your password or banking details, so that’s bad.