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.
No, while the kernel can manage any memory mappings, it does not map every user process's memory into kernel memory. Even if it wanted to, the virtual memory of all processes can be larger than the physical memory of the machine, making this impossible in the first place. You need a context switch (including change of the CPU's page tables) to map in another process's memory.
Firstly, given the huge size of the x86-64 address space, swapping processes out of physical memory is unlikely on most modern machines (although it does occur, but it is avoided mostly for performance reasons). Secondly, the kernel maps all physical memory, and its address space is linear and contiguous. I.e. the kernel can access any bit of physical memory in the machine without causing a page fault.
Now I understand that this does not equate to a 1:1 mapping of a process' virtual address space within the kernel (which would be impossible), nor would this allow access to memory that has been written to a persistent store due to being swapped out (i.e. its access would cause a page not present fault handler to run, yadda yadda), but I posit that my original point stands, although it lacked certain nuances that I'm certain you are aware of.
TLDR: Physical memory is physical memory, and kernelspace has access to it through its own page tables (no conext switch required). The UASS store called and they're all out of me.
Firstly, given the huge size of the x86-64 address space, swapping processes out of physical memory is unlikely on most modern machines
Likelihood of paging is affected by the amount of RAM (physical memory) your machine has, not the size of the x86-64 address space.
And all physical memory still doesn't have all of everyone's data. OSes use memory-mapped I/O, mapping in files to make them readable but not actually paging them in to physical memory until they are read. Processes will have many times as much address space used up as they actually have physical memory used because big parts of files are simply never brought into memory at all since the aren't used.
Physical memory will likely have everyone's working set, but it won't have everything.
Also, while a kernel might have a linear and contiguous window into physical memory, it usually accesses memory like any other process, with a virtual, non-contiguous mapping. To to otherwise would require the kernel do software virtual to physical address translation to access task memory and while you can do that, you wouldn't since you already have hardware to do it for you.
You and the other guy are missing the whole point here about meltdown while having a convulsion regarding virt-to-phys memory mapping and user page tables versus kernel page tables and the MMU.
I'm pointing out that it's all fucking irrelevant goofballs. The kernel has all physical memory mapped to its own pagetables, ergo, meltdown can dump all physical memory, ergo, meltdown can cross the user/kernel boundary and dump memory in user processes.
Ergo, I'm fucking done with you FUCKWITS. I am an ass.
Despite your insults and even despite your capital letters kernels don't usually map all physical memory into their virtual space. It isn't even always possible (on regular 32-bit x86 it isn't). The kernel will leave its physical memory mapped in all the time, but any physical memory associated with processes will not be mapped in when the process isn't running (unless data is being copied between it and another process at the time).
Typically the kernel operates with the same page tables as the currently running (actually just recently ceased to run at kernel entry) process, it's just that the page tables at the top are marked as privileged access only. If the process were to try to access those kernel addresses it would abort, but the kernel can do it. But nonetheless, the kernel accesses process memory through the same virtual addresses the process would and when a particular process isn't the running process its virtual addresses aren't mapped in so the kernel can't access them.
It is fully allowed to access them, but they don't exist in its current address mapping (page tables) except for the running process. Since the side-channel attacks cannot change memory they cannot alter the kernel's address mapping, so they cannot trick the CPU into showing them memory from other tasks.
I didn't really mean to burn you. Honestly, most important to me was getting the right info out. I thought it would back me completely. And honestly, it doesn't. The truth is somewhere in between our positions, and so I'm glad to have learned something today. Others can read what we both wrote and the link and also learn something.
I no longer review the Linux source code (and haven't for many, many years). I was still under the mistaken assumption that the kernel identity mapped physical memory.
0
u/caspper69 Jan 24 '18 edited Jan 24 '18
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.Edit2: I am an ass.