What's the difference of the Userland vs the Kernel? [duplicate]

Question

I am trying to understand exactly what is userland? everyone that I ask says: "Anything that is not kernel". but it is not tangible for me. When I am reading that kernel can run that driver on the userland or something like that; I can't quite imagine what will happen!. So I will appreciate if someone set me straight in this regard.

Answer 1

On one conceptual level, the kernel is everything that runs at a "more privileged" level of hardware protection. That would be like ring 0 on x86 processors, system mode on ARM, kernel mode on MIPS, supervisor mode on 68xxx, etc. The kernel is usually interrupt-driven, either software interrupts (system calls) or hardware interrupts (disk drives, network cards, hardware timers).

On that same conceptual level, "user land" is what runs in the least privileged mode (ring 3 on x86 CPUs, user mode on ARM or MIPS, etc.). User land takes advantage of the way that the kernel smooths over minor hardware differeences, presenting the same API to all programs. For instance, some wireless cards might have extra control registers with respect to others, or contain more or less on-board buffer for incoming packets. The driver code accounts for these differences (sometimes by ignoring advanced or unusual features), and presents the same socket API to all programs.

Some processors (e.g. x86, VAX, Alpha AXP) have more than two modes, but the generic Unix architecture doesn't use the intermediate modes.

The programs and processes you see running in Unix or Linux or *BSD are the user land. Since processes are pre-emptible, you actually never see the kernel run, you just see side effects, like a read() system call returning, or a signal handler function running.

To answer your specific question, in Unix, Linux, *BSD a "driver" is usually some smallish piece of software that deals with the specific peculiarities of some piece of hardware: a network card, a disk drive, a video card. The driver software almost always neeeds to run in Ring 0/supervisor mode/kernel space in order to have access to hardware interrupts, or the mapped memory of the hardware or whatever. The driver takes care of specific hardware features, and makes that hardware fit into the kernel code's standardized or conventionalized view of how hardware should work. Therefore, running a driver in user land requires the kernel to show a userland program things like mapped-in memory or device registers or interrupts or other special features. That can be tricky, as the special features a device might require don't easily fit in to the usual Unix-style API presented to user land programs. Also, scheduling is an issue, as user land programs don't typically respond to interrupts all that rapidly.

Answer 2

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 lsmod, insmod, modprobe, and rmmod).

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.

Answer 3

Building on what Bruce said, all code that is provided to the kernel must be trusted. If there is someway that malicious code can be executed by the kernel, it's game over. That is where the privilege separation of user executed code and kernel executed code comes into play. Code that is ran by a user doesn't necessarily have to be 100% free from evil. It does not get executed directly by the kernel.

Userland programs simply interact with exposed portions of the kernel, such as APIs and loaded modules. An example would be iptables. There are several kernel modules (.ko) or 'drivers' that actually do the work of iptables, they're part of the netfilter framework. When you execute commands using /sbin/iptables you're using the userland component which in turn communicates with the netfilter modules that are loaded into the kernel. This allows separation so that user code cannot inadvertently be executed by the kernel.

Answer 4

One way to get a good and thorough understanding of these concepts would be to go trough a tutorial like those on osdev.org or James Molloy's Tutorial.

Linux has a monolithic Kernel, this means that its code runs entirely in ring 0 on the x86 architecture, as Bruce stated. Thus, having full control of all the resources, the Kernel will manage all requests for them by user level applications (running in the least privilege level 3)

Think of this: if applications from user space had full access to virtual memory - RAM - they could trash everything, from other processes' stacks or heaps to kernel's internal buffers. The kernel maps pages to each process's page directory, and if the application misbehaves by trying to access a location which does not belong to its address space, then it will be forcedly shut down.

Next, think what would happen if each program would have direct access to a printer or some other output device. Two concurrent instances of processes trying to print to the printer would scramble everything up, but if these requests go trough the kernel, then they will be queued and treated separately, resulting in two separate printed pages.

Further, since machines usually have a smaller number of processors than processes currently running, the kernel uses a scheduler to switch between processes, each getting its own finite time to use the processor. When this time expires, it will be moved to the end of a list of active processes, or to a list of inactive ones - if the process has been waiting for data from some device. This way, all processes seem to be running concurrently although only one process, or the kernel gets to use one processor at any given moment. This concept is called pseudo parallelism.

Regarding your last question on drivers on user land: this is possible, still, the kernel keeps full control over the communication with the device. For example, the Kernel may map a region of kernel memory to the user-space driver's memory region, thus giving it access to the device memory. Kernel still has the power to forward changes to the device or not. This user land driver will provide with a nice interface for controlling the device to other user applications, and if somehow the driver crashes, there may still be good chances for it to be reloaded without having to reset the machine. If the driver had been in kernel space, say a module, if the module got stuck and can't be unloaded, then it can't be re-loaded either because it's symbols are already there, so the only chance is to reset the machine.

To conclude, applications like cat top or a "hello world" only run in user space, having access to system's resources ONLY trough the Kernel API, which is a set of functions called system calls. So, when an application issues a read() system call to read from a file, then the kernel takes control of the processor, reads data using the appropriate driver (like HDD driver), and then copies this data back into the address provided by the pointer passed to the read() system call, letting the application continue to run as soon as this data is available.

Answer 5

In Unix/Linux operating systems, we differ between user space and kernel space. That are just synonyms for userland and where the kernel belongs to.

You can understand it as follows. You can interact with all that goes on in the user space. Which is not the case in the kernel space. Daemons, libraries and applications belong to the user space. All code which runs outside the operating system's kernel belongs to the user space (userland).

The kernel space is where the kernel itself runs. It's a restricted area where not even root has access to. But the root user can manipulate some kernel parameters by an interface, provided by the kernel (procfs, sysfs).

System memory is a good example to explicate the difference between kernel and user space. A daemon (that runs in user space) need some memory to run. The kernel manages all the memory that is available. The daemon gets some "virtual memory" from the kernel, where the daemon is not aware of whether it's physical memory or swap space or whatever. The kernel is the one that determines which kind of memory the process gets. Because memory management happens in the kernel space. Other things that happen in the kernel space are process scheduling, inter-process communication, memory protection and management, system calls...

What exactly is userland?

So, userland is what the daemon does (or can do) when interacting with the operating systems ressouces (I/O, network, memory, cpu time). Those ressources are hidden from the process in the kernel space.

The short answer:

It's what the cockpit of a plane for the pilot is.

Answer 6

You already got several good answers, but I think there's also value in a short and concise answer:

Modern CPUs allow to restrict what specific code is allowed to do. "Kernel mode" refers to unrestricted code with full access to the hardware. "Userland" is code with restricted permissions. If userland code wants to access anything but its own memory, it has to call the kernel, which then checks permissions before performing the requested action.

Answer 7

Various layers within Linux, also showing separation between the userland and kernel space

for full image
Source

Answer 8

At first I will agree that there are here many great answers.
My contribution will be the shortest definition I found years ago about the kernel in a Linux system administration book: "kernel: the memory resident part of the os".