User space and kernel space
Overview
The term userland (or user space) refers to all code that runs outside the operating system's kernel.[1] 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.
User mode | User applications | bash, LibreOffice, GIMP, Blender, 0 A.D., Mozilla Firefox, ... | ||||
---|---|---|---|---|---|---|
System components | init daemon: OpenRC, runit, systemd... |
System daemons: polkitd, smbd, sshd, udevd... |
Window manager: X11, Wayland, SurfaceFlinger (Android) |
Graphics: Mesa, AMD Catalyst, ... |
Other libraries: GTK, Qt, EFL, SDL, SFML, FLTK, GNUstep, ... | |
C standard library | fopen , execv , malloc , memcpy , localtime , pthread_create ... (up to 2000 subroutines)glibc aims to be fast, musl aims to be lightweight, uClibc targets embedded systems, bionic was written for Android, etc. All aim to be POSIX/SUS-compatible. | |||||
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[2] | ||||
Process scheduling subsystem | IPC subsystem | Memory management subsystem | Virtual files subsystem | Networking subsystem | ||
Other components: ALSA, DRI, evdev, klibc, LVM, device mapper, Linux Network Scheduler, Netfilter Linux Security Modules: SELinux, TOMOYO, AppArmor, 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.
Another approach taken in experimental operating systems is to have a single address space for all software, and rely on the programming language's virtual machine 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.[3][4] This approach has been implemented in JXOS, Unununium as well as Microsoft's Singularity research project.
See also
References
- ^ "userland, n." The Jargon File. Eric S. Raymond. Retrieved 2016-08-14.
- ^ "Admin Guide README". Kernel.org git repositories.
- ^ "Unununium System Introduction". Archived from the original on 2001-12-15. Retrieved 2016-08-14.
{{cite web}}
: Unknown parameter|deadurl=
ignored (|url-status=
suggested) (help) - ^ "uuu/docs/system_introduction/uuu_intro.tex". UUU System Introduction Guide. 2001-06-01. Retrieved 2016-08-14.
External links
- Linux Kernel Space Definition
- Entering User Mode at the Wayback Machine (archived March 26, 2016)