The fourth week of the Linux kernel analysis notes the three-layer skin (top) of the system call

Three layers of skin (top) of the system call

One, the user state, the kernel state and interrupts

The library function encapsulates the system call.

1, what is the user state and the kernel state

In general, modern CPUs have several different levels of instruction execution.

At high execution level, the code can execute privileged instructions and access any physical address , which corresponds to the kernel state of the CPU execution level.

In the corresponding low-level execution state ( User state ), the code is limited in scope of control. can only be active within the scope allowed by the corresponding level. The system is prone to crashes.

There are four different levels of execution in Intel X86cpu 0,1,2,3,linux use only 0 and 3 to represent the kernel State and user state.

2, in the Linux kernel code to distinguish between the user state and the kernel state

Use CS(Code Snippet selector register) and EIP(offset register) to differentiate.

The lowest two bits of the CS register indicate the privilege level of the current code.

Access in the kernel State: CS and EIP values can be any address. Address space (address space above 0xc0000000): the logical address.

User-state access: 0XC0000000-0XBFFFFFFF address space.

3, interrupt processing is the main way to enter the kernel state from the user state

System calls are just a special kind of interrupt.

A. Register context:

When switching from the user state to the kernel State:

The register context of the user state must be saved

Saves the kernel-State register context to the current CPU

B. The interrupt/int instruction will save some register values on the stack:

User state the top address of the stack, the state word at the time, the value of the ES:EIP at that time (the entry of the interrupt handler).

At the same time, the stack top address of the kernel state stack, the state word at the time, and the entry point to the interrupt handler are pointed to the system call function.

C. The first thing that happens after an interruption is to save the scene.

Protect the scene is: entered the Interrupt Service program to save the required register data,

　　　　　　Recovery site is: Exit the interrupt program, restore the data to save the register.

The iret instruction is the opposite of what the CPU does when the interrupt signal (including the int command) occurs.

D. Complete process of interrupt processing

　　　　　　

/* System call */

/* Save the CS:EIP value holds the current stack segment register at the top and the flag register to the kernel stack */

/* The entry of the interrupt service routine associated with the current interrupt signal (System call) is loaded into CS:EIP */

/* The current stack segment and ESP point to the kernel stack are also loaded into the CPU */

After the completion of the above process, the current CPU in the execution of the next instruction, it is already executing the interrupt handler entry, the operation of the stack from the original user state to the kernel state.

Process scheduling may occur during the completion of the interrupt service.

If no process scheduling occurs, execute:

Returns the original state.

If a process schedule occurs:

The current state will be saved in the system, and the next time the process is scheduled to be switched back to the current process, the process is completed.

II. Overview of System invocation

1, the meaning of system call

The operating system provides a set of interfaces for user-state processes to interact with hardware devices-system calls

• Freeing the user from the underlying hardware programming (the operating system manages the hardware to prevent system crashes from direct contact with the hardware device)
• Greatly improves the security of the system
• Enables user programs to be portable (the user program is decoupled from the specific hardware and is replaced by an abstract interface that is not closely related to the specific hardware)

2. API and System calls

A. The application programming interface (application program interface, API) and system calls are different.

• API is just a function definition
• System call sends an explicit request to the kernel via a soft interrupt (for example, Sysrem enter command)

Some APIs defined by the B.LIBC library refer to the encapsulation routines (wrapper routine, the only purpose is to publish system calls so that programmers do not need to use assembly instructions to start a system call when writing code, but instead call a function directly)

• Typically each system call corresponds to an encapsulation routine
• The library then uses these encapsulation routines to define the API for the user

? C. Not every API corresponds to a specific system call. (possibly one-to-many or more-to-a)?

• API may directly provide user-configured services? For example, some mathematical functions?
• A separate API might invoke several system calls?
• Different APIs may call the same system call?

D. return value?

• Most package routines return an integer whose meaning depends on the corresponding system call?
• 1 in most cases the kernel does not satisfy the request of the process?
• The errno variable defined in LIBC contains a specific error code

　　　　　　　　　　　　User-State Kernel state

　

　function xyz ()             A system call is encapsulated in the API, 0x80 Interrupt vector corresponds to system call (kernel code entry start)

Executes the corresponding interrupt service program SYS_XYZ () after return from SYS call

Process scheduling may occur and return iret if not occurring

　　　　　　　　　　　　　　　　The system call triggers a 0x80 interrupt

　　　　The system calls the corresponding API

system call three-layer skins: xyz, System_call, sys_xyz(API, interrupt vector corresponding Interrupt service program, multiple service programs in system call)

3. System invoke programs and service routines
A. When the user-state process invokes a system call, the CPU switches to the kernel state and starts executing a kernel function. (Interrupt vector 0x80 is bound to System_call, and system calls associate XYZ with SYS_XYZ).

• In Linux, which executes a system call by executing an int $0x80, this assembly instruction produces a programming exception with a vector of 128
• The sysenter directive (fast system call) was introduced in Intel Pentium II and 2.6 has been supported (this course does not consider this)
  ?

B. Transfer of parameters:
The kernel implements a number of different system calls,
The process must indicate which system call is required, which requires passing a parameter called the system call number .
? using the EAX register to pass
Parameter passing methods for system calls:

1) system calls also require input and output parameters, such as

• The actual value.
• The address of the variable in the user-state process address space.
• Even the address of a data structure that contains pointers to user-state functions.

? 2) System_call is the entry point for all system calls in Linux, with at least one parameter per system call, which is the system call number passed by eax

• An application calls the fork () encapsulation routine, the value of the EAX register is set to 2 (that is, __nr_fork) before the int $0x80 is executed.
• The setting of this register is done in the encapsulation routines in the LIBC library, so the user generally does not care about the system call number.
• Immediately after entering Sys_call, the value of EAX is pressed into the kernel stack.

? 3) The Register pass parameters have the following limitations:
• The length of each parameter cannot exceed the length of the register, which is 32 bits.
• In addition to the system call number (EAX), the number of parameters cannot exceed 6 (EBX, ECX,EDX,ESI,EDI,EBP).
• What if there are more than 6 of them? Use a register as a pointer to a piece of memory, enter the kernel state to access all the address space, and pass the data through that block of memory.

Third, using the Library function API and C code embedded assembly code to trigger the same system call

1. System Invoke Experiment: example: Using library function API to get system current time

/* Declare a TIME_TT variable */

/* Declares a TM for output to become readable */

/* Use time system call to return tt*/

/* Convert TT into T-format */

/* Output */

Get the current system time:

The experimental implementation uses the Library function API to obtain a real user ID (getuid):

Compile getuid.c to get the current real user id:

Use the C code to embed the assembly code to trigger the system call to get the system's current real user id:

EBX return to zero

Using the EAX delivery system call number 24

The return value of the system call is stored using the EAX

The result is the same as before.

Iv. Summary

The system call is the interface between the user program and the kernel. Through the system call process, the user state can be transferred to the kernel, in the kernel state to complete the corresponding service, and then return to the user state. This approach will inevitably span the two patterns we have just mentioned: kernel and user state. System call is a set of interfaces that the operating system provides for the interaction between the user-state process and the hardware device, and the meaning is to liberate the user from the hardware programming, greatly improving the security of the system and the portability of the users ' programs. In the experiment, using the Library function API and C code in the embedded assembly code to trigger the same system call, in this experiment I use the library function to obtain the real user identification number (GETUID), and using C code embedded assembly code to trigger system calls to obtain the system's current real user identification code, the process seems easy, In fact, it took a long time to open a hot spot to do experiments or something, hoping for the next time to lay a good foundation for learning.

The fourth week of the Linux kernel analysis notes the three-layer skin (top) of the system call