week. At least, I think its simplified 🙂

There are 3 variants to the problem, and all 3 are based on "speculative execution", which has been around for a very long time and is a means of achieving higher performance. When code that is executing reaches a branch, it can take some time to figure out which path of code should actually be followed. Instead of sitting there twiddling its thumbs while waiting for this, the CPU tries to predict which branch it will take and will speculatively start executing code down that path. If the prediction was right- great, you just saved a bunch of time! If not, the CPU throws out all of that stuff that it did speculatively and then starts down the right path. This is basic stuff that has been taught to students since the 1990s.

The researchers that found this exploit were trying to find if any information was left around from speculatively executed code that had been thrown out because of a misprediction, and they found some. Here is the basic flow of all 3 variants of the exploit which allows you to determine the value of any single bit in memory:

- Have the CPU predict the wrong branch and start to speculatively execute instructions down the wrong path
- In those speculatively executed instructions, have a conditional based on some memory that the code should not have access to. If that conditional evaluates to true, then load some previously uncached memory into cache. Of course, the code trying to access memory that it shouldn't isn't allowed and would cause an exception, but we wouldn't find that out until the branch is resolved and we know if we should be executing these instructions in the first place.
- The CPU then figures out it was executing the wrong path and rolls back all of the speculative execution, throwing out all of the results (and no need to raise an exception for the code trying to access memory that it shouldn't because the results were thrown out). But the problem is that last load- it is still in the cache when it wasn't before. That's the information left behind that the researchers found.
- Now the exploit reads that last location. If the read comes back very quickly, that address was in the cache, so that means that the bit that they shouldn't be able to see was a '1'. If it takes a while (cache miss), that means the bit was a '0'.

Using this method, the exploit can go bit-by-bit through some other memory that you shouldn't have access at the rate of about 2kbps to determine its value. The 3 variants are where the other memory is located (physical memory, protected kernel memory, etc) and some other tricks to delay that first branch prediction and buy yourself more time in speculative execution. All modern CPUs that do branch prediction are vulnerable to the basic premise of the exploit. Intel and ARM64 (but not AMD) also have the problem that those speculative reads can be to kernel memory. AMD actually blocks those reads to a higher protection level, so while they are vulnerable to reading memory with the same protection level, you can't read kernel memory using this method.