System Call Principle

1. What is system call?

System calling, as the name implies, refers to a set of "special" interfaces provided by the operating system for user programs. User Programs can use this set of "special" interfaces to obtain the services provided by the operating system kernel. For example, users can request the system to open files, close files, or read/write files through file system-related calls, you can obtain the system time or set the timer through system calls related to the clock.

Logically speaking, a system call can be considered as an interface for the interaction between the kernel and the user space program. It is like a man-in-the-middle interface that transmits user process requests to the kernel, after the kernel processes the request, it returns the result to the user space.

The root cause for system services to be provided to the user space through system calls is to "Protect" the system, because we know that Linux runtime space is divided into kernel space and user space, they run at different levels and are logically isolated from each other. Therefore, user processes generally do not allow access to kernel data or use kernel functions. They can only operate on user data and call user space functions. For example, the familiar "Hello World" Program (during execution) is a standard user space process. The print function printf is a user space function, the printed "Hello word" string also belongs to user space data.

However, in many cases, a user's process needs to obtain system services (call system programs). In this case, you must use the "special interface" provided to the user by the System-system call, its particularity mainly lies in specifying the specific location where the user process enters the kernel. In other words, the path for the user to access the kernel is specified in advance and can only enter the kernel from the specified location, and cannot jump into the kernel. With such a restriction on the unified access path of the kernel, the kernel security can be ensured. We can vividly describe this mechanism: as a tourist, you can buy a ticket to request to enter the Safari Park, but you must honestly sit on a sightseeing car and follow the prescribed route for sightseeing. Of course, you are not allowed to get off the bus because it is too dangerous, either to let you lose your life or to scare wild animals.

2 LinuxSystem Call 

For modern operating systems, system calling is a universal means of kernel-to-user space communication, and Linux systems are no exception. However, compared with many systems such as UNIX and windows, the system calls of Linux have some unique characteristics, which show the essence of Linux design-simplicity and efficiency.

Linux system calls inherit the UNIX system calls (but not all) in many places. However, compared with traditional UNIX system calls, it saves many redundant system calls of UNIX systems and only retains the most basic and useful system calls, therefore, there are only about 250 calls in all Linux systems (and more than 1000 calls in some operating systems ).

First, you must understand the main usage of system calls in the kernel. Although several categories are given above, in general, the main usage of system calls in the system is nothing more than the following:

L control hardware-system calls are often used as abstract interfaces of hardware resources and user space, such as write/read calls used to read and write files.

L set the system status or read the kernel data-because system calling is the only means of communication between the user space and the kernel [1] [2], the user sets the system status, for example, to enable/disable a kernel Service (set a kernel variable) or read kernel data, it must be called by the system. For example, getpgid, getpriority, setpriority, and sethostname

L process management-a system call interface is used to ensure that the system process can run in a virtual memory environment with multiple tasks. For example, fork, clone, execve, and exit.

Second, what services should exist in the kernel; or what functions should be implemented in the kernel rather than in the user space. There is no clear answer to this question. Some services can be completed in the kernel or in the user space. The following considerations are generally taken into account when selecting to complete the kernel:

L The service must obtain kernel data. For example, some services must obtain kernel data such as interruption or system time.

L From the security perspective, the services provided in the kernel are undoubtedly safer than those provided by the user space, and it is difficult to be accessed illegally.

L from the perspective of efficiency, the kernel implementation service avoids the steps of transferring data back and forth with the user space and protecting the site. Therefore, the efficiency is often much higher than that in the user space. For example, httpd and other services.

L if the kernel and user space need to use this service, it is best to implement it in the kernel space, such as random number generation.

Understanding the above principles is of great significance to understanding the nature of system calls. It is hoped that netizens can sum up and think more from the usage.

3Relationship between system calls, user programming interfaces (APIS), system commands, and kernel functions 

System calling does not directly deal with programmers or system administrators. It is just an interface that uses the Soft Interrupt mechanism (which we will talk about later) to submit requests to the kernel to obtain kernel services. In actual use, programmers call user programming interfaces-APIs, while administrators use system commands.

A User Programming Interface is actually a function definition that describes how to obtain a given service, such as read (), malloc (), free (), and ABS. It may be consistent with the system call form. For example, the read () interface corresponds to the read system call, but this correspondence is not one-to-one, there are usually several different APIs that use the same system call internally. For example, malloc () and free () Use BRK () System Call internally to expand or reduce the process heap; or an API uses a combination of several system calls to complete the service. Some APIs do not even need to be called by any system-because they are not required to use kernel services, such as the ABS () interface for calculating the absolute value of integers.

In addition, Linux User programming interfaces follow the POSIX standard, the most popular application programming interface standard in the Unix world, which defines a series of APIs. In Linux (Unix as well), these APIs are mainly implemented through the C library (libc). Besides defining some standard C functions, A very important task is to provide a set of wrapper routine to package system calls in user space for programming.

Next, we need to explain the relationship between kernel functions and system calls. We should not think of kernel functions as too complex. In fact, they are very similar to common functions, but are implemented in the kernel. Therefore, we must meet some kernel programming requirements [3]. A system call is an interface for a user to enter the kernel. It is not a kernel function. after entering the kernel, different system calls will find corresponding kernel functions. In other words, the system calls are called: the system calls the service routine. In fact, kernel functions rather than calling interfaces are used to provide services for requests.

For example, the system calls getpid to call the kernel function sys_getpid.

Asmlinkage long sys_getpid (void)

{

Return Current-> tpid;

}

In Linux, there are many kernel functions, some of which are used by the kernel files, and some of which can be used by other parts of the kernel through export.

Run the command ksyms or CAT/proc/ksyms to view the kernel function exposed by the kernel -- export. In addition, there is also a book titled the Linux kernel API book for inductive classification kernel functions on the Internet. If you are interested, you can check it out.

All in all, from the perspective of users to the kernel, there are system commands, programming interfaces, system calls, and kernel functions in sequence. After describing the implementation of the system call, we will look back at the entire execution path.

4. Implementation of system calls
In Linux, system calls are implemented using software interruptions in the 0x86 architecture [4]. Software interruptions are different from what we often call hardware interruptions because they are triggered by software commands rather than peripheral interruptions. That is to say, it is also an exception developed by programmers. Specifically, it is to call the int $0x80 Assembly command, which will generate a programming exception with a vector of 128.

The reason why system calls need to be implemented with exceptions is that when a user-state process calls a system call, the CPU is switched to the kernel state to execute the kernel function [5]. in the architecture section of i386, we have already talked about how to enter the kernel-to enter the High-privilege level-to pass through the system's door mechanism, the exception here is actually thrown into the kernel through the system gate (in addition to int 0x80, the user space can also enter the kernel through abnormal commands such as int3 -- Vector 3, into -- Vector 4, bound -- Vector 5, etc, other exceptions cannot be used by user space programs, which are used by the system ).

We will explain this process in more detail. The purpose of the int $0x80 command is to generate a programming exception numbered 128, which corresponds to the 128th item in the IDT of the Interrupt Descriptor Table-that is, the corresponding system gate descriptor. The gate descriptor contains a preset kernel space address, which points to the system call handler: system_call () (do not confuse with the system call service program, this program is in the entry. s files are written in assembly languages ).

Obviously, all system calls are directed to this address, but in Linux, there are two or three hundred system calls from here, after entering the kernel, how should we distribute them to their respective service programs? Don't faint. The solution to this problem is very simple: first, Linux numbers (0-nr_syscall) for each system call, and saves a system call table in the kernel, this table stores the system call numbers and their corresponding service routines. Therefore, before the system call is transferred to the kernel through the system gate, the system call numbers must be passed into the kernel together, on x86, this transfer operation is implemented by loading the call number into the eax register before int0x80 is executed. In this way, once the system call handler runs, you can obtain data from eax and then search for the corresponding service routine in the system call table.

In addition to the system call number, many system calls also need to pass some parameters to the kernel, such as sys_write (unsigned int FD, const char * Buf, size_t count) for a call, you need to pass the file descriptor FD, the content Buf to be written, and the number of bytes to be written to the kernel. In this case, Linux has six registers that can be used to pass these parameters: eax (storing the system call number), EBX, ECx, EDX, ESI, and EDI are used to store these additional parameters (in ascending order of letters ). The specific method is to use the save_all macro in system_call () to save the values of these registers in the kernel state stack.

From: http://hi.baidu.com/ahunspun/blog/item/4620954be9e483f783025c06.html