Spectre Mitigations Part 1 | Hacker News Reader

Spectre Mitigations Part 1

wasmjit.org

45 pointscejetvole6 comments

I was confused over the discussed mitigations because it seemed they were fixing attacker code. So all the attacker would have to do was omitting the mitigations.

Turns out the attacker only controls the input, not the function itself in the Spectre scenario. Looks like I finally understood the difference between Meltdown and Spectre :-)

My informal understanding.

Meltdown: out of order execution of reading a secret and cache it in L3 via a predictable pattern through page aligned indexes from 0 * page_size to 255 * page_size

Spectre: (speculative) out of order execution through: direct branches, function calls, and returns (same cache side channel strategies as meltdown)

Biggest difference: meltdown will segfault. Spectre won’t.

Didn’t check the source code of spectre but that of meltdown is pretty clear, especially when you read the paper.

The biggest difference is that meltdown is cross privilege level. ie. it lets user space read arbitrary memory mapped to kernel space.

I wonder whether that is true. I'm uncertain about the following (due to not understanding virtual memory to physical memory translation and isolated processes well enough) but I could imagine the following or a variant of it:

unmapping the kernel is not enough if another thread still has access to it. From my undertanding: if a process has access to a kernel space memory address. Then as the attacker you train the branch predictor unit to dereference a certain address in kernel space, then the thread/core that has access to it dereferences it and then it'll be cached.

What I don't understand is that if you dereference a virtual memory address the whole time whether you're then training the BPU to remember that address (and that other processes will be influenced if they dereference the same virtual address) or that you're training the BPU to dereference the physical address behind it. It really depends on whether the BPU happens before the MMU or after.

Well whether my reasoning is right or not according to the following post Spectre can also read kernel memory: https://googleprojectzero.blogspot.com/2018/01/reading-privi...

The reason why you can use Spectre to read kernel memory is that there is a JIT'd runtime in the kernel (BPF). There is no privilege boundary crossing because you are effectively running code in the context of the kernel.

They're a jit, they can rewrite the attacker code.

Reply on news.ycombinator.com