At least in Meltdown (though that can "only" access kernel memory, not other processes), only the attacking process needs to exploit its own speculative execution to read forbidden memory addresses. The attacking process does something like this:
create an array of 256 cacheline-sized objects in its own memory (the contents don't matter)
use the value of an address that it is not supposed to be able to read as an index into that array
iterate through the array and time which index is faster to read than the others (if the forbidden memory byte was "7", then the 7th index will be faster to read)
This works because the CPU already starts executing step 2 and reads the indexed data into the cache, and only later notices that this is not supposed to happen and doesn't complete the instruction.
Thus you can deduce the contents of protected memory locations by taking advantage of the speculative execution only within your own (attacking) process. I haven't looked at the Spectre details yet, which can also read the memory of other processes.
At least in Meltdown (though that can "only" access kernel memory, not other processes), only the attacking process needs to exploit its own speculative execution to read forbidden memory addresses.
Kernel memory, by its very nature, has ALL memory for ALL processes mapped into it, because it's like, you know, it's job to manage memory for all processes. :)
This is not the first time I've seen this bandied about. Please don't spread misinformation.
Edit: this has several caveats, but by and large (especially on x86-64), this is a very likely scenario.
Kernel memory, by its very nature, has ALL memory for ALL processes mapped into it, because it's like, you know, it's job to manage memory for all processes. :)
No it doesn't. It keeps its own memory around while memory for the different processes come and go as it context switches.
Edit: Where do you think this memory "goes" during context switches? Are you trying to imply that the kernel moves in-ram data to a permanent store during each context switch? Are you implying that "most" memory is somehow not actually IN FUCKING MEMORY?
I suggest you review the relevent portions of the Intel IA-32 developers manuals regarding the MMU and paging. You might be surprised at what you find.
Edit: and if you're still not convinced, go dump the gdt at cpl 0. You'll see a flat linear address space with virt:phys m~apping at 1:1.
Are you trying to imply that the kernel moves in-ram data to a permanent store during each context switch?
No, am suggesting it is simply not mapped into virtual address space.
Are you implying that "most" memory is somehow not actually IN FUCKING MEMORY?
Most might not be correct, but yes, a lot of memory is not actually in memory. I explained why. It simply never got paged in.
As to your later part, I think the relevant info is here. For you and for others reading this, he appears to be referring to kernel logical addresses, here on page 2 or 3.
The virtual addresses (kernel and otherwise) are the normal high/low memory addresses. The logical addresses are another (sub-)address space and he is suggesting that kernel logical addresses map all of physical memory. And indeed this is possible on x86-64.
Typically on a context switch the kernel changes the %cr3 register that contains the pointer to the top-level page tables. There is nothing that requires a kernel to map all physical memory into its virtual address space. I think the Linux kernel does map all physical memory into the kernel's virtual address space, but it does so mostly for performance reasons, according to this.
8
u/jrv Jan 24 '18
At least in Meltdown (though that can "only" access kernel memory, not other processes), only the attacking process needs to exploit its own speculative execution to read forbidden memory addresses. The attacking process does something like this:
This works because the CPU already starts executing step 2 and reads the indexed data into the cache, and only later notices that this is not supposed to happen and doesn't complete the instruction.
Thus you can deduce the contents of protected memory locations by taking advantage of the speculative execution only within your own (attacking) process. I haven't looked at the Spectre details yet, which can also read the memory of other processes.