User space

Short description: Software run under a kernel

A modern computer operating system usually segregates virtual memory into kernel space and user space. Primarily, this separation serves to provide memory protection and hardware protection from malicious or errant software behaviour.

Kernel space is strictly reserved for running a privileged operating system kernel, kernel extensions, and most device drivers. In contrast, user space is the memory area where application software and some drivers execute.

Overview

The term userland (or user space) refers to all code that runs outside the operating system's kernel. Userland usually refers to the various programs and libraries that the operating system uses to interact with the kernel: software that performs input/output, manipulates file system objects, application software, etc.

Each user space process normally runs in its own virtual memory space, and, unless explicitly allowed, cannot access the memory of other processes. This is the basis for memory protection in today's mainstream operating systems, and a building block for privilege separation. A separate user mode can also be used to build efficient virtual machines – see Popek and Goldberg virtualization requirements. With enough privileges, processes can request the kernel to map part of another process's memory space to its own, as is the case for debuggers. Programs can also request shared memory regions with other processes, although other techniques are also available to allow inter-process communication.

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

User mode	User applications	For example, bash, LibreOffice, GIMP, Blender, 0 A.D., Mozilla Firefox, etc.
	Low-level system components:	System daemons: systemd, runit, logind, networkd, PulseAudio, ...	Windowing system: X11, Wayland, SurfaceFlinger (Android)	Other libraries: GTK+, Qt, EFL, Software:Simple DirectMedia Layer|SDL]], SFML, FLTK,GNUstep|GNUstep]], etc.		Graphics: Mesa, AMD Catalyst, ...
	C standard library	open(), exec(), sbrk(), socket(), fopen(), calloc(), ... (up to 2000 subroutines) glibc aims to be POSIX/SUS-compatible, musl and uClibc target embedded systems, bionic written for Android, etc.
Kernel mode	Linux kernel	stat, splice, dup, read, open, ioctl, write, mmap, close, exit, etc. (about 380 system calls) The Linux kernel System Call Interface (SCI, aims to be POSIX/SUS-compatible)
		Process scheduling subsystem	IPC subsystem	Memory management subsystem	Virtual files subsystem	Network subsystem
		Other components: ALSA, DRI, evdev, Logical Volume Manager (Linux)|LVM]], device mapper, Linux Network Scheduler, Netfilter Linux Security Modules]]: SELinux, TOMOYO, AppArmor, Smack (Linux security module)|Smack]]
Hardware (CPU, main memory, data storage devices, etc.)

Implementation

The most common way of implementing a user mode separate from kernel mode involves operating system protection rings. Protection rings, in turn, are implemented using CPU modes. Typically, kernel space programs run in kernel mode, also called supervisor mode; normal applications in user space run in user mode.

Many operating systems are single address space operating systems -- they have a single address space for all user-mode code. (The kernel-mode code may be in the same address space, or it may be in a second address space). Many other operating systems have a per-process address space, a separate address space for each and every user-mode process.

Another approach taken in experimental operating systems is to have a single address space for all software, and rely on a programming language's semantics to make sure that arbitrary memory cannot be accessed – applications simply cannot acquire any references to the objects that they are not allowed to access. This approach has been implemented in JXOS, Unununium as well as Microsoft's Singularity research project.

See also

• BIOS
• CPU modes
• Early user space
• Memory protection

External links

• Linux Kernel Space Definition