[go: nahoru, domu]
Jump to content

User space and kernel space: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
ʘx (talk | contribs)
392 edits
→‎Implementation: Programming languages have nothing to do with virtual machines. In particular, they don' t "have" machines. Instead, they have semantics.
→‎Implementation: Don't commit to "many" for single-address-space operating systems or per-process-address-space operating systems.
 
(29 intermediate revisions by 26 users not shown)
Line 1: Line 1:
{{Short description|Way of using computer memory}}
⚫
{{selfref|For the term "user space" as used in Wikipedia, see [[Wikipedia:User pages]].}}
{{Redirect|Kernel space|the mathematical definition|Null space}}
{{Redirect|Kernel space|the mathematical definition|Null space}}
⚫
{{for|the user space on Wikipedia|Wikipedia:User pages}}
{{ref improve|date=October 2012}}
{{more citations needed|date=October 2012}}


A modern computer [[operating system]] usually segregates [[virtual memory]] into '''kernel space''' and '''user space'''.{{efn|Older operating systems, such as [[DOS]] and [[Windows 3.1x]], do not use this architecture.}} Primarily, this separation serves to provide [[memory protection]] and hardware protection from malicious or errant software behaviour.
A modern computer [[operating system]] usually uses [[virtual memory]] to provide separate address spaces, or separate regions of a single address space, called '''user space and kernel space'''.<ref>{{cite web|url=https://linux-kernel-labs.github.io/refs/heads/master/lectures/address-space.html#address-space-options-for-32bit-systems|title=Address space|at=Address space options for 32bit systems}}</ref>{{efn|Older operating systems, such as [[DOS]] and [[Windows&nbsp;3.1x]], do not use this architecture.}} Primarily, this separation serves to provide [[memory protection]] and hardware protection from malicious or errant software behaviour.


{{anchor|KERNEL}}
{{anchor|KERNEL}}
Kernel space is strictly reserved for running a privileged [[operating system kernel]], kernel extensions, and most [[device driver]]s. In contrast, user space is the memory area where [[application software]] and some drivers execute.
Kernel space is strictly reserved for running a privileged [[operating system kernel]], kernel extensions, and most [[device driver]]s. In contrast, user space is the memory area where [[application software]] and some drivers execute, typically one address space per process.


== {{Anchor|USERLAND}}Overview ==
== {{Anchor|USERLAND}}Overview ==
The term '''userland''' (or user space) refers to all code that runs outside the operating system's kernel.<ref>{{cite web
The term '''user space''' (or '''userland''') refers to all code that runs outside the operating system's kernel.<ref>{{cite web
| url = http://www.catb.org/jargon/html/U/userland.html
| url = http://www.catb.org/jargon/html/U/userland.html
| title = userland, n.
| title = userland, n.
| work = The [[Jargon File]]
| work = The [[Jargon File]]
| publisher = [[Eric S. Raymond]]
| publisher = [[Eric S. Raymond]]
| accessdate = 2016-08-14}}</ref> Userland usually refers to the various programs and [[library (computing)|libraries]] that the operating system uses to interact with the kernel: software that performs [[input/output]], manipulates [[file system]] objects, [[application software]], etc.
| access-date = 2016-08-14}}</ref> User space usually refers to the various programs and [[library (computing)|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 (computing)|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 [[debugger]]s. Programs can also request [[Shared memory (interprocess communication)|shared memory]] regions with other processes, although other techniques are also available to allow [[inter-process communication]].
Each user space [[process (computing)|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 [[debugger]]s. Programs can also request [[Shared memory (interprocess communication)|shared memory]] regions with other processes, although other techniques are also available to allow [[inter-process communication]].
Line 22: Line 23:


== Implementation ==
== Implementation ==
The most common way of implementing a '''user mode''' separate from [[supervisor mode|kernel mode]] involves operating system [[Protection ring|protection rings]].
The most common way of implementing a '''user mode''' separate from [[supervisor mode|kernel mode]] involves operating system [[protection ring]]s.
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.

Some operating systems are [[single address space operating system]]s—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).
Other operating systems have a per-process address space, with 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 [[reference (computer science)|reference]]s to the objects that they are not allowed to access.<ref>{{cite web
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 [[reference (computer science)|reference]]s to the objects that they are not allowed to access.<ref>{{cite web
| url=http://uuu.sourceforge.net/si.php#SEC6
| url=http://uuu.sourceforge.net/si.php#SEC6
| title=Unununium System Introduction
| title=Unununium System Introduction
| archiveurl=https://web.archive.org/web/20011215052223/http://uuu.sourceforge.net/si.php#SEC6
| archive-url=https://web.archive.org/web/20011215052223/http://uuu.sourceforge.net/si.php#SEC6
| archivedate=2001-12-15
| archive-date=2001-12-15
| url-status=dead
| deadurl=yes
| accessdate = 2016-08-14}}</ref><ref>{{cite web
| access-date = 2016-08-14}}</ref><ref>{{cite web
| url=http://uuu.cvs.sourceforge.net/viewvc/uuu/uuu/docs/system_introduction/uuu_intro.tex?view=markup
| url=http://uuu.cvs.sourceforge.net/viewvc/uuu/uuu/docs/system_introduction/uuu_intro.tex?view=markup
| title=uuu/docs/system_introduction/uuu_intro.tex
| title=uuu/docs/system_introduction/uuu_intro.tex
| work=UUU System Introduction Guide
| work=UUU System Introduction Guide
| date=2001-06-01
| date=2001-06-01
| accessdate = 2016-08-14}}</ref> This approach has been implemented in [[JX (operating system)|JXOS]], Unununium as well as Microsoft's [[Singularity (operating system)|Singularity]] research project.
| access-date = 2016-08-14}}</ref> This approach has been implemented in [[JX (operating system)|JXOS]], Unununium as well as Microsoft's [[Singularity (operating system)|Singularity]] research project.


== See also ==
== See also ==
* [[BIOS]]
* [[BIOS]]
* [[CPU modes]]
* [[CPU modes]]
* [[Early user space]]
* [[Memory protection]]
* [[Memory protection]]
* [[OS-level virtualization]]


==Notes==
==Notes==

Latest revision as of 23:13, 16 June 2024

"Kernel space" redirects here. For the mathematical definition, see Null space.
For the user space on Wikipedia, see Wikipedia:User pages.

A modern computer operating system usually uses virtual memory to provide separate address spaces, or separate regions of a single address space, called user space and kernel space.[1][a] 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, typically one address space per process.

Overview

[edit]

The term user space (or userland) refers to all code that runs outside the operating system's kernel.[2] User space 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 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[3]
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

[edit]

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.

Some 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). Other operating systems have a per-process address space, with 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.[4][5] This approach has been implemented in JXOS, Unununium as well as Microsoft's Singularity research project.

See also

[edit]

Notes

[edit]
  1. ^ Older operating systems, such as DOS and Windows 3.1x, do not use this architecture.

References

[edit]
  1. ^ "Address space". Address space options for 32bit systems.
  2. ^ "userland, n." The Jargon File. Eric S. Raymond. Retrieved 2016-08-14.
  3. ^ "Admin Guide README". Kernel.org git repositories.
  4. ^ "Unununium System Introduction". Archived from the original on 2001-12-15. Retrieved 2016-08-14.
  5. ^ "uuu/docs/system_introduction/uuu_intro.tex". UUU System Introduction Guide. 2001-06-01. Retrieved 2016-08-14.
[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_space_and_kernel_space&oldid=1229460749"