Anatomy of a system invocation by embedding assembly code in library function APIs and C code

Kuregaku Shandong Normal University "Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

The main content of this experiment is to call System_call in the way of API and GCC embedding assembly respectively.
The system call is actually the service provided by the operating system. We usually write the program, if it is only numerical calculation, then all the process is done in the user state, but we want to print the variable on the screen, we must call printf, and printf This function inside the use of write this system call.
The operating system provides service as system call because it is extremely dangerous if the programmer can manipulate all of the OS's resources, so the OS designs the kernel state and the user state.
We usually program in the user state, if we want to invoke system resources, then we must adopt the system call, into the kernel state, in order to achieve the purpose.

Following the experimental process, the two methods are described in one by one.

First, the Library function API, write the function of time, the function is to implement display the current times.

Second, compile and open the program

Third, the Time-asm function is written by the way of embedding assembly, the function ibid.

The application of system calls is very extensive and contains almost all functions except scientific operations. There are two ways to make a system call under the Linux platform: by using the encapsulated C Library (LIBC) or by assembly-direct invocation.
System calls under Linux are implemented by means of interrupts (int 0x80). When the int 80 instruction is executed, the function number of the system call is stored in the register eax, and the parameters passed to the system call must be placed in the Register Ebx,ecx,edx,esi,edi in order, and when the system call is complete, the return value can be obtained in the register EAX.
All system call function numbers can be found in the file/usr/include/bits/syscall.h, for ease of use, they are defined with a macro such as sys_<name>, such as Sys_write, Sys_exit, and so on. For example, the write function that is often used is defined as follows:
ssize_t Write (int fd, const void *buf, size_t count);
The function is ultimately implemented by Sys_write, the system call. According to the above conventions, the parameters FB, BUF and count respectively exist in registers ebx, ECX and edx, and the system call number Sys_write is placed in register EAX, when the int 0x80 instruction is executed, the return value can be obtained from register EAX.
Perhaps you have found that at most only 5 registers can be used to save parameters when making system calls, is there not more than 5 parameters for all system calls? Of course not, for example, the MMAP function has 6 parameters, which need to be passed to the system call Sys_mmap at the end:
void * Mmap (void *start, size_t length, int prot, int flags, int fd, off_t offset);
When the number of parameters required for a system call is greater than 5 o'clock, the execution of the int 0x80 instruction is still required to save the system call function number in the register eax, except that all parameters should be placed sequentially in a contiguous area of memory while holding a pointer to the memory area in the register EBX. After the system call is complete, the return value will still be saved in the register EAX.
Because only a contiguous area of memory is required to hold the parameters of the system call, it is entirely possible to use the stack to pass the parameters required by the system call like normal function calls. Note, however, that Linux uses the C-language invocation pattern, which means that all parameters must be stacked in the opposite order, that is, the last parameter is first in the stack, and the first parameter is the last one in the stack. If the stack is used to pass the parameters required by the system call, the current value of the stack pointer should also be copied to the register ebx when the int 0x80 instruction is executed.

Four, after compiling the experimental effect ibid.

V. Summary: The mechanism of system invocation

1. When a task (process) executes a system call and is executed in the kernel code, we say that the process is in the kernel run state (or simply kernel State). At this point the processor is executed in the highest privileged (level 0) kernel code. When the process is in the kernel state, the kernel code that executes will use the kernel stack of the current process. Each process has its own kernel stack. When the process executes the user's own code, it is said to be in the user's running state (user state). That is, the processor is running in the least privileged (level 3) user code. When the user program is being executed and the program is interrupted abruptly, the user program can also be symbolically referred to as the kernel state in the process. Because the interrupt handler will use the kernel stack of the current process. This is somewhat similar to the state of a process that is in a kernel state.
2. Computer architecture is probably divided into such layers from the bottom up: physical hardware, OS kernel, OS services, applications. In this four-tier structure, the OS kernel acts as a "nexus" that manages the physical hardware and provides an interface for OS services and applications upwards. The idea is that the interface here actually refers to system call.
3. Usually the OS kernel is designed to be difficult to implement and manageable, providing only a small subset of the necessary system calls, which are usually implemented by C and assembler. The interface is defined by C and is written by the assembly. The advantage of this is that the execution is efficient, and it greatly facilitates the upper-level invocation.
4. Say the library function (i.e. API). Library functions can be broadly divided into two categories, one is provided with the OS, and the other is third-party. With the library functions provided by the system to further encapsulate or combine system calls, to achieve more functions, like the C language of many functions of a single small function to achieve many many functions of a large number of complex functions. Such an API can perform some complex operations relative to the kernel, for example, the read () function according to parameters, directly read the file, and hidden behind such as the file on the hard disk of which track, which sector, loaded into the memory where and so on these operations, the programmer is not concerned about, These operations also naturally contain system calls. For a third-party library, it is actually the same as the system library, but it is less likely to make direct use of system calls, but instead uses the API interface provided by the system to implement the function.

Anatomy of a system invocation by embedding assembly code in library function APIs and C code