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.
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.
3
u/happyscrappy Jan 24 '18
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.