the kernel address space
Every running program sees memory through virtual addresses - a private map the hardware translates to real physical memory. The kernel address space is the portion of that map reserved for the kernel itself: the addresses where kernel code, kernel data structures, and direct mappings of physical memory live. The crucial design choice in systems like Linux is to split each process's virtual address range into two halves - a user part the program may freely touch, and a kernel part it is forbidden to touch directly - and to keep the kernel half mapped identically in every process, so the kernel is 'always there' no matter which process is running.
Picture a 64-bit address range as a long ruler. The low addresses (say up to 0x7fffffffffff) are user space: your code, your stack, your heap, your libraries. The high addresses are kernel space: only the kernel may read or write them. The page tables mark kernel pages as privileged, so if user-mode code so much as dereferences a kernel pointer, the CPU refuses and raises a fault. When a system call or interrupt takes you into the kernel, the CPU switches to its privileged mode and now those high addresses become usable; on the way back out, that privilege is dropped again. Because the kernel half is shared across processes, entering the kernel does not require swapping in a whole new memory map - the kernel is already mapped above the line.
This split is the architectural backbone of memory protection and of the kernel as a trust boundary. It is exactly why the kernel cannot blindly follow a pointer a user program handed it - the pointer might point into kernel space or to nothing at all - which is the whole reason copy_to_user and copy_from_user exist. A subtlety worth knowing: side-channel attacks like Meltdown forced kernels to stop fully sharing the kernel mapping into user page tables (a mitigation called page-table isolation), trading some speed for safety, which shows this 'always mapped above the line' picture is a simplification with security exceptions.
x86-64 (simplified): user space 0x0 .. 0x00007fffffffffff | kernel space 0xffff800000000000 .. up. User code dereferencing a kernel address -> CPU page fault, killed; only privileged mode may touch the high half.
The virtual range is split: user code may touch only the low half; the high half is the kernel's, mapped into every process but privileged.
'Kernel space' is a range of virtual addresses with privileged page permissions, not a separate physical chip. A user pointer is meaningful only inside that process's user half - which is why the kernel must validate and copy user pointers rather than dereferencing them directly.