Why is kernel mapped to the same address space as processes?

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.

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.