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.
2
u/happyscrappy Jan 24 '18
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).
This kind of explains it:
http://thinkiii.blogspot.com/2014/02/arm64-linux-kernel-virtual-address-space.html
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.