Most modern CPUs have a kernel or supervisor mode, and a restricted user mode. This is a hardware feature of the CPU. "Userland" is another name for code running in user mode.
One big difference between the modes is with regards to how the MMU of most moden CPUs acts under them.
An MMU allows a kernel to rearrange blocks (or pages) of RAM so they appear to code in a different order than they are physically in RAM, and also cause user mode code to trap or "fault" back to kernel mode if certain pages are accessed. User mode cannot change what the MMU does, only the kernel mode can do that.
So, the MMU allows kernel mode code to do all sorts of cool things, like:
- "arrange" or "map" memory to user mode code so such code thinks it has contiguous RAM.
- implement a dynamic memory management scheme where a process would need to ask for memory before trying to use it.
- stop user processes if they use memory they aren't supposed to.
- swap out least-used pages to disk if free memory runs low and swap them back in when a process tries to access them.
You can see that the MMU, along with kernel/user mode, is the cornerstone of a multitasking operating system, and using these tools one can create a system that works with higher-level things like the idea of processes. A kernel is maintaining page tables for each process and basically reprogramming the MMU before it switches to user mode and gives control over to a process for its timeslice. Things like
malloc and stuff where a process acquires memory is causing the kernel to modify MMU page tables.
Again, user mode can't do anything to the page tables (and doesn't really need to know they exist), if it needs memory, it needs to call the kernel, which causes a switch from user mode to kernel mode. CPUs provide a simple mechanism called a software interrupt to do this, and there are other faster ways that the Linux kernel uses.
Because of this protection that exists in user mode, if a program does something like crash or go haywire and overwrite itself, the kernel can stop this process. In kernel mode, this protection does not exist, so the kernel will stop working and thus your entire system will also stop working. When an unrecoverable error like this happens in kernel mode, it is called a kernel panic. See What is a "kernel panic"? for details.
kernel can run that driver on the userland
The kernel or supervisor mode of CPUs also prevents user mode from directly accessing I/O devices, the idea is that it has to call the kernel to do that. In Linux, code that talks to devices directly (they run in kernel mode) are device drivers (a type of kernel module, you can manipulate them with commands like
What happens if your device driver, which would be running in kernel mode under the simplest setup, has a bug and does something nasty like overwrite random stuff in RAM (and since it's in kernel mode, it has unrestricted access to all RAM and can overwrite the kernel itself). It be nice if we could get the device driver running in user mode, so that it can't do anything to the kernel itself or other processes.
Unfortunately, switching from user to kernel mode (called a context switch) is slow, since basically the entire state of the CPU has to be switched in and out for each process or the kernel itself. So, we have two things at odds, safety or speed, and thus it's a point of contention and design.
Kernels that try to do as much as possible in user mode are called microkernels, and Linux is the opposite, which is called monolithic. User-mode drivers do exist for Linux (look into FUSE for an example) and there's even a framework that allows it.