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.
Imagine what would happen if the kernel is not mapped in each process address space.It would triple fault because say the timer interrupt occurs,then the processor calls the ISR routine using IDT(Interrupt Descriptor Table).If the kernel is not mapped then the IDT address becomes invalid and thus a triple fault will result.
Another important reason why we say kernel is in the process address space is that kernel can access the user code/data of the CURRENT process, i.e. the virtual address space 0~3G.
Sorry about my poor English. I am not a native English speaker.
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.
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 is to try to 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.