This is a question to elaborate on this one: Why is kernel said to be in process address space?
This might be a silly question but it just popped up in my mind. All the text about process address space and virtual memory layout mentions that the process address space has space reserved for kernel. For e.g. on 32 bit systems the process address space is 4GB of which 1 GB is reserved for kernel in Linux (Might be different on other OS).
I am just wondering why kernel is said to be in the process address space when a process cannot address the kernel directly. Why don't we say that the kernel has a separate address space than a process and why can't we have a different page table for kernel itself which is separate from the page tables of the processes?
Can I get an explanation with respect to Linux (Debian or Ubuntu) specific operating system?
Just like there has to be a separate place for each process to hold its set of saved registers (in its process table entry), each process also needs its own kernel stack, to work as its execution stack when it is executing in the kernel.
The kernel address space is statically mapped into the address space. The top 1 GB of the user's space is reserved for system elements while the bottom 1 GB holds the user code, data, stack, and heap.
Recently, Linux and other OSes have implemented page-table isolation (PTI) to mitigate the Meltdown security vulnerability. With PTI, the kernel does have its own address space (as the image from Wikipedia shows).
Primarily, this separation serves to provide memory protection and hardware protection from malicious or errant software behaviour. Kernel space is strictly reserved for running a privileged operating system kernel, kernel extensions, and most device drivers.
To answer another part of the question - the kernel is mapped into every processes address space partially for efficiency/performance reasons (there are others too, I'm sure).
On most modern hardware, it is quicker to change the security level (thus allowing access to the pages that are otherwise protected, as mentioned in Alexey's answer) in order to perform system calls and other kernel provided functions than it is to change the security level and the entire virtual memory map, along with all the associated TLB cache flushes and everything else involved in a full context switch.
Since system calls can be fairly frequent events, the design that has evolved in Linux and many other places to try and minimize the overhead of utilizing kernel services, and mapping the kernel code and (at least some of the) data into each process is part of that.
A process "owns" the entire virtual address space here, the kernel and the user portions of it.
Its inability to peek and poke the kernel code and data is not due to different address spaces, it's due to different access rights/permissions set in the page tables. Kernel pages are set up in such a way that regular applications can't access them.
It is, however, customary to refer to the two parts of one whole thing as the kernel space and the user space and that can be confusing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With