3 ms·
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
by mettamage 8y ago
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-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
- cyphar 8y agoThe 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.