To clear things up a little further, the embargo on information has come down so we know what the attacks are. Specifically there are two, one called Meltdown, and one called Spectre.
Meltdown, as far as can be told right now, only affects Intel CPUs. It is the one that requires the kernel page table isolation that affects performance.
Spectre operates on similar principles but doesn't break kernel security. It is less dangerous than Meltdown (though not benign to be sure) and affects Intel, AMD, and ARM processors equally.
The way they both work is pretty interesting actually. I'll explain Meltdown for you all. So, the processor will not actually let you access or use data speculatively accessed when the instructions are fully resolved. So here is the basic example given, here register RCX contains a protected kernel memory address, and register RBX contains the address of a large array you have allocated in user space. Also AL is an 8-bit register that is simply the lowest byte of the 64-bit RAX register:
1: mov AL, byte [RCX]
2: shl RAX, 0xC
3: mov RBX, qword [RBX + RAX]
Line 1 tries to access 1 byte of data from the address in RCX. Line 2 takes the RAX register, which now contains that data in it's lowest byte, and shifts it left 12 bits. so if the contents of RAX looked like this: 0x00000000000000FF, after instruction 2 it now looks like this: 0x00000000000FF000. Finally line 3 tries to read the location of the user space array offset by the current value of RAX. So if the array is located at user space memory address 0x00000000F000000, it will try to load the data in the array located at address 0x000000F00FF000.
Now when instruction 1 is finally fully resolved, the CPU will throw a fault because your user process isn't allowed to access the address in RCX, and all the work done by instructions 2 and 3 is reverted. You will
not find the contents of memory address RBX + RAX in register RBX after this snippet of code. So how does the exploit work? Well this is the cool part, and should give those of you asking how this took so long to figure out an idea of why stuff like this could be hard to find.
Here is what happens. I mentioned before that the CPU contains caches for the data it pulls from main memory. This means that if a piece of memory has been recently accessed, when you access it again it will be much faster. So what you do to exploit this is you make sure your large user space array is "cold", meaning not present in the CPU cache. You try the exploit which contains the above code, hoping the CPU will attempt to speculatively execute it. Then you
time how long it takes to load data from different points in the array! The purpose of line 2 is to spread out the addresses in the array that will be read based on the data read from kernel memory, so each entry is 4096 bytes away from any other, making sure touching one doesn't include another in it's cache line. Once you time the memory accesses for the array, you see that accessing memory address 0x000000F00FF000 only took 1 ns, while the other 255 memory locations you tried to access took 100 ns each. Now you know that the kernel contained the byte FF at the memory location that was stored in RCX.
This is amazing in my opinion. You use the nature of caching that we use to keep our CPUs as busy as they can potentially be in order to generate a timing attack to determine the contents of memory we don't have access to!
)
Laugh all you want at its slower speed but I'm secure baby.