Chapter 4 of "Some Problems with ARM and Linux": Analysis of the Principles of System Calls on the ARM Platform

This article is based on the mstar801 platform Linux2.6.35.11 version.

First of all, it should be noted that system calls do not cause process context switching.

1. Introduction to system call - the only way for Linux user space to actively enter kernel space

    1. System call is a set of "special" interfaces provided by the operating system to user programs for calling; user programs can obtain services provided by the operating system kernel through this set of "special" interfaces.

       Logically speaking, a system call can be seen as an interface for interaction between the kernel and user space programs; the user process's request is conveyed to the kernel, and the kernel sends the processing result back to the user space after processing the request.

    2. System calls can be roughly divided into several categories according to their functional logic: "process control", "file system control", "system control", "storage management", "network management", "socket control", "user management" and "inter-process communication".

    3. Kernel interface: kernel2.6.35.11/arch/arm/include/asm/unistd.h

2. The main purpose of system calls

    1. Control hardware - system calls often serve as an abstract interface between hardware resources and user space, such as the write/read calls used when reading and writing files.

    2. Setting system status or reading kernel data - Because system calls are the only means of communication between user space and the kernel, users must use system calls to set system status, such as turning on/off a kernel service (setting a kernel variable) or reading kernel data, such as getpid, getpriority, setpriority, and sethostname.

    3. Process management - The system call interface is used to ensure that processes in the system can run in a virtual memory environment as multiple tasks, such as fork, clone, execve and exit.

3. The relationship between kernel functions and system calls, user programming interfaces (APIs), and system commands

    1. System calls do not directly interact with programmers or system administrators. They are just an interface that submits requests to the kernel through the soft interrupt mechanism and obtains kernel services. In actual use, programmers mostly call user programming interfaces (APIs), while administrators mostly use system commands.

    2. The user programming interface (API) is actually a function definition that explains how to obtain a given service, such as read(), malloc(), free(), abs(), etc.

       It may be consistent with the system call format, for example, the read() interface corresponds one-to-one with the read system call;

       Often, the same system call is used internally by several different APIs, such as malloc() and free(), which use the brk() system call internally to expand or reduce the process heap;

       Or an API uses a combination of several system calls to complete a task;

       Some APIs do not even require any system calls because they do not require kernel services, such as the abs() interface for calculating the absolute value of an integer.

       These APIs in the Linux system are mainly implemented through the C library (libc); in addition to defining some standard C functions, an important task is to provide a set of encapsulation routines to package system calls in user space for user programming.

       Note: The above encapsulation is not necessary; if you prefer to call directly, Linux provides a syscall() system call function to implement the call.

    3. System commands are one level higher than programming interfaces. They are executable programs that reference APIs internally, such as the commonly used system commands ls, hostname, etc.

3. The relationship between kernel functions and system calls

    Kernel functions are not as complicated as you might think; they are very similar to ordinary functions, except that they are implemented in the kernel and therefore must meet some kernel programming requirements.

    The system call is an interface for users to enter the kernel. It is not a kernel function itself. After entering the kernel, different system calls will find their corresponding kernel functions - the professional term is: system call service routine.

    Summary: From the user's perspective to the kernel, there are system commands, programming interfaces, system calls, and kernel functions
.

    System calls utilize software interrupts in the ARM architecture. The difference between software interrupts and what we often call interrupts (hardware interrupts) is that they are triggered by software instructions rather than peripherals, that is, an exception issued by the programmer; specifically, it calls the SWI assembly instruction (int $0x80 on x86). This assembly instruction will generate a programming exception with vector 128. ARM switches from user mode to management mode and forces R15-PC (program counter) to 0x0000 0008. Linux enters kernel mode from user mode. See: Chapter 1 of "Some Problems with ARM and Linux": ARM Working Mode

    The reason why system calls need to be implemented with the help of exceptions is that when a process in user mode calls a system call, the CPU is switched to kernel mode to execute kernel functions. In the previous analysis of ARM architecture, we have already mentioned that to enter kernel mode - ARM high privilege mode, we must go through the system gate mechanism - exceptions (SWI assembly instructions (int $0x80 on x86, etc.); other exceptions cannot be used by user space and are all used by the kernel.).

    1. The purpose of the SWI assembly instruction (int $0x80 on x86) is to generate a programming exception numbered 128, which corresponds to the 128th item in the interrupt descriptor table IDT - that is, the corresponding system gate descriptor. The gate descriptor contains a preset kernel space address, which points to the system call handler: vector_SWI() (system_call() on x86). Note: not the system call service program itself.

    That is: system command -> user programming API -> system call (call SWI assembly instruction exception) -> system call processing function (vector_SWI) -> specific system call service program. The blue part is the kernel state function.

    2. All user space system call functions enter kernel state by calling the SWI assembly instruction (int $0x80 on x86). At this time, ARM executes the program from a fixed address by default (the address of vector_SWI() (system_call() on x86)). How does the kernel function vector_SWI() (system_call() on x86) distribute these system calls to their respective kernel service programs? Linux numbers each system call (0-_NR_syscall); at the same time, a system call table is saved in the kernel, which stores the system call number and its corresponding service routine. Therefore, before the system call falls into the kernel through the gate, the system call number needs to be passed to the kernel. This transfer is achieved by loading the system call number into the corresponding register.

    With the above analysis: once the system call handler vector_SWI() (system_call() on x86) is running, it can get data from the corresponding registers, and then look for the corresponding service routine in the system call table.

    Note: In addition to the system call number, some system calls also need to pass some parameters to the kernel; this is Linux passing the parameter values ​​to other registers when calling vector_SWI() (system_call() on x86).

    When the kernel system service routine ends, system_call() obtains the system call return value from the corresponding register and places the return value at the location where the corresponding user-mode register stack unit was saved; then it jumps to ret_from_sys_call() to terminate the execution of the system call handler.

================================================== ================================================== ================================

5. Main Paths

1. User space: There is no research code in the libc library. The general mechanism is as follows:

                       Call the SWI assembly instruction (int $0x80 on x86) to enter the kernel soft interrupt and pass in the interrupt vector number

                       Related interrupt vector number arm-2010.09/arm-none-linux-gnueabi/libc/usr/include/bits/syscall.h

                           #define SYS_getuid __NR_getuid

2. Kernel space: System call number definition path in ARM: kernel2.6.35.11/arch/arm/include/asm/unistd.h
                           #define __NR_getuid (__NR_SYSCALL_BASE+ 24)  

                      Exception entry kernel space function path: kernel2.6.35.11/arch/arm/kernel/entry-common.s

                          The default implementation of vector_SWI (system_call() on x86) function                       

                       System call table definition path in ARM: kernel2.6.35.11/arch/arm/kernel/calls.S 

                           CALL(sys_getuid) //The 24th one, which should correspond to the previous unistd

                       Declaration path of the system call service program in ARM: kernel2.6.35.11/include/linux/syscalls.h

                           asmlinkage long sys_getuid(void);

================================================== ================================================== ================================

x86 platform related paths (kernel):

    System call number path——kernel2.6.35.11/arch/x86/include/asm/unistd.h

    system_call() function path——kernel2.6.35.11/arch/x86/kernel/entry.S

    System call table path——kernel2.6.35.11/arch/x86/kernel/syscall_table.S or defined directly in entry.S