yosh

If you've done exploitation before, you'll probably recognise this as being similar to a ROP gadget. We're looking for a sequence of code in kernel space that happens to have the right sequence of instructions to leak information via cache.

Keep in mind that the execution is speculative only - the processor will later realise that I didn't have the privilege to jump to that code and throw an exception. So the target code has to leak kernel data via cache side-channels like before.

You'll also notice that we need to know address of the target kernel code. With KASLR this isn't so easy. Project Zero's writeup explains how KASLR can be defeated using branch prediction and caching as side-channels, so I won't go into the details here. https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html …

What makes this extra powerful is that it works across VM boundaries too. Instead of a traditional indirect jump (e.g. jmp eax), we can use the vmcall instruction to speculatively execute code within the VM host's kernel in the same way we would our VM's kernel.

Finally, there's the third approach. This involves a flush+reload cache attack against kernel memory, similar to the first variant of the attack but without requiring kernel code execution - it can all be done from usermode.

The idea is that we try to read kernelspace memory using a mov instruction, then perform a secondary memory read with an address based on the value that was read. If you're thinking the first mov will fail because we're in usermode and can't read kernel addresses, you're right.

The trick is that the microarchitectural implementation of mov contains the memory page privilege level check, which itself is a branch instruction. The processor may speculatively execute that branch like any other.

So, if you can outrun the interrupt, you can speculatively execute some other instruction that loads data into cache based on the value read from kernelspace. This then becomes a cache attack like the previous tricks.