
Spectre Mitigations Part 1 - cejetvole
https://www.wasmjit.org/blog/spectre-mitigations-part-1.html
======
lolc
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 :-)

~~~
mettamage
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.

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

~~~
mettamage
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...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-
memory-with-side.html)

~~~
cyphar
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.

