System call

It has been suggested that Supervisor Call instruction be merged into this article or section. (Discuss)

In computing, a system call is how a program requests a service from an operating system's kernel that it does not normally have permission to run. System calls provide the interface between a process and the operating system. Most operations interacting with the system require permissions not available to a user level process, e.g. I/O performed with a device present on the system, or any form of communication with other processes requires the use of system calls.

Contents 1 Privileges 2 The library as an intermediary 3 Examples and tools 4 Typical implementations 5 References 6 External links

[edit] Privileges

The fact that improper use of the system call can easily cause a system crash necessitates some level of control. The design of the microprocessor architecture on practically all modern systems (except some embedded systems) offers a series of rings or CPU modes -- the (low) privilege level in which normal applications execute limits the address space of the program so that it cannot access or modify other running applications nor the operating system itself. It also prevents the application from directly using devices (e.g. the frame buffer or network devices). But obviously many normal applications need these abilities; therefore, pre-defined system calls are made available by the operating system. The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often implemented through interrupts. If allowed, the system enters a higher privilege level, executes a specific set of instructions over which the interrupting program has no direct control, returns to the calling application's privilege level, then returns control to the calling application. This concept also serves as a way to implement security.

With the development of separate operating modes with varying levels of privilege, a mechanism was needed for transferring control safely from lesser privileged modes to higher privileged modes. Less privileged code could not simply transfer control to more privileged code at any point and with any processor state. To allow it to do so would allow it to break security. For instance, the less privileged code could cause the higher privileged code to execute in the wrong order, or provide it with a ba .

[edit] The library as an intermediary

Generally, systems provide a library that sits between normal programs and the operating system, usually an implementation of the C library (libc), such as glibc. This library exists between the OS and the application, and increases portability.

On exokernel based systems, the library is especially important as an intermediary. On exokernels, libraries shield user applications from the very low level kernel API, and provide abstractions and resource management.

The terms "system call" and "syscall" are often incorrectly used to refer to C standard library functions, particularly those that act as a wrapper to corresponding system calls with the same name. The call to the library function itself does not cause a switch to kernel mode (if the execution was not already in kernel mode) and is usually a normal subroutine call (i.e. using a "CALL" assembly instruction in some ISAs). The actual system call does transfer control to the kernel (and is more implementation-dependent than the library call abstracting it). For example, "fork" and "execve" are GLIBC functions that in turn call the "fork" and "execve" system-calls.

[edit] Examples and tools

On Unix, Unix-like and other POSIX-compatible operating systems, popular system calls are open, read, write, close, wait, execve, fork, exit, and kill. Many of today's operating systems have hundreds of system calls. For example, Linux has over 300 different calls, and FreeBSD has almost 500.^[1]

Tools such as strace and truss allow a process to execute from start and report all system calls the process invokes, or can attach to an already running process and intercept any system call made by said process if the operation does not violate the permissions of the user. This special ability of the program is usually also implemented with a system call, e.g. the GNU's strace is implemented with ptrace().

[edit] Typical implementations

Implementing system calls requires a control transfer which involves some sort of architecture-specific feature. A typical way to implement this is to use a software interrupt or trap. Interrupts transfer control to the operating system kernel so software simply needs to set up some register with the system call number needed, and execute the software interrupt.

For many RISC processors this is the only technique provided, but CISC architectures such as x86 support additional techniques. One example is SYSCALL/SYSENTER, SYSRET/SYSEXIT (the two mechanisms were independently created by AMD and Intel, respectively, but in essence do the same thing). These are "fast" control transfer instructions that are designed to quickly transfer control to the OS for a system call without the overhead of an interrupt. Linux 2.5 began using this on the x86, where available; formerly it used the INT instruction, where the system call number was placed in the EAX register before interrupt 0x80 was executed.^[2]

An older x86 mechanism is called a call gate and is a way for a program to literally call a kernel function directly using a safe control transfer mechanism the OS sets up in advance. This approach has been unpopular, presumably due to the requirement of a far call which uses x86 memory segmentation and the resulting lack of portability it causes, and existence of the faster instructions mentioned above.

For IA-64 architecture, EPC (Enter Privileged Mode) instruction is used. The first eight system call arguments are passed in registers, and the rest are passed on the stack.

System calls can be roughly grouped into five major categories:

1. Process Control.
   • load
   • execute
   • create process
   • terminate process
   • get/set process attributes
   • wait for time, wait event, signal event
   • allocate, free memory
2. File management.
   • create file, delete file
   • open, close
   • read, write, reposition
   • get/set file attributes
3. Device Management.
   • request device, release device
   • read, write, reposition
   • get/set device attributes
   • logically attach or detach devices
4. Information Maintenance.
   • get/set time or date
   • get/set system data
   • get/set process, file, or device attributes
5. Communication.
   • create, delete communication connection
   • send, receive messages
   • transfer status information
   • attach or detach remote devices

[edit] References

1. ^ "FreeBSD syscalls.c, the list of syscall names and IDs". http://fxr.watson.org/fxr/source/kern/syscalls.c. 
2. ^ Anonymous (2002-12-19). "Linux 2.5 gets vsyscalls, sysenter support". KernelTrap. http://kerneltrap.org/node/531. Retrieved 2008-01-01. 

[edit] External links

• Linux system call reference - Updated system call reference for Linux kernel 2.6, includes register and data structure references
• A list of modern Unix-like system calls
• Interactive map of Linux kernel
• Linux system calls - system calls for Linux kernel 2.2, with IA-32 calling conventions
• How System Calls Work on Linux/i86
• Sysenter Based System Call Mechanism in Linux 2.6
• Kernel command using Linux system calls - IBM developerWorks
• HOWTO for Implementing a System Call on Linux 2.6 - Amit Choudhary
• Modular system programming on Minix 3
• A simple open Unix Shell in C language - examples on System Calls under Unix

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.