Chapter 12 Principles of System Calls
1. Ordinary applications run in user mode, and the only way to enter the kernel mode is through a system interrupt. Interrupts are divided into hardware interrupts and software interrupts. Software interrupts generally enter the system interrupt handler with int number 0x80. Interrupt numbers are very good, so generally interrupt numbers and system calls have a one-to-many relationship. Under Linux, system calls are triggered through the 0x80 interrupt. The system call number is passed through eax, and the parameters are passed in other registers.
The triggering of the interrupt is also accompanied by the transition from the user stack to the kernel stack, and ss, esp, eflags, cs, and ip are pushed into the kernel stack to facilitate return to the user program. All this is done automatically by int through hardware.
The interrupt handler No. 0x80 first pushes the 6 registers used as system call parameters on the stack, then determines that the call number does not exceed the boundary, and finally calls the system call indirectly through the system call table stored in sys_call_table.
When the system call function is executed, the parameters are obtained directly from the stack. There is an asmlinkage identifier in front of each function, which instructs the compiler that this function only obtains parameters from the stack.
2. Since the performance of system calls based on int instructions is not good on Pentium 4th generation processors, Linux began to support a new system call mechanism in version 2.5, which supports a set of dedicated system call instructions – sysenter and sysexit.
When using the ldd command to obtain the shared library dependencies of the executable file, you can see that a shared library Linux-gate.so.1 does not correspond to any actual file. Because it is just a virtual dynamic shared library (VDSO) generated by the operating system, it is always loaded at address 0xffffe000. Export it to a real file
via
dd if=/proc/self/mem of=Linux-gate.dso bs=4096 skip=1048574 count=1 . Through objdump -T, you can see that vdso exports a series of functions, including the __kernel_vsyscall function. Through objdump -d --start-address= --stop_address= disassembly to view the first 8 bytes of the function, you can see sysenter. After calling it, the system jumps directly to the execution of the function specified by a certain register, and automatically completes the privileges Level conversion, stack switching and other functions. Parameter passing is exactly the same as using int system calls. Parameters are also passed through these 6 registers, and SAVE_ALL is also used to put parameters on the stack in the kernel.
3. Windows API
Windows API refers to the lowest level and most direct interface for dealing with Windows provided to application developers in the Windows operating system. Under Windows, the CRT is built on the Windows API. There are also many various packaging libraries for Windows API. For example, MFC is a well-known library packaged in C++.
That is to say, when calling the Windows API, it does not enter the kernel, but calls the system call in the Windows API.
Unlike Linux, the runtime library directly calls system calls.
Windows API is exposed to applications in the form of dll export functions. Microsoft provides developers with the declaration header files, export libraries, related files and tools of these Windows API DLLs, called SDKs. SDKs
can be downloaded separately and may be integrated into development tools such as VS.
In Windows NT, all DLL implementations rely on a lower-level DLL called NTDLL.DLL, which makes system calls.
Since the Windows API is still relatively primitive, Windows has also built many application modules on top of the API. These modules are extensions to the functions of the Windows API.
The purpose of the Windows API is to provide backward compatibility for applications. Because system calls are actually interfaces that are very dependent on the hardware structure.
The second is to provide compatibility between different versions of the kernel of Windows itself.
Windows API exists in the form of DLL because DLL itself is the most basic module organization form of Windows system.
In order to be compatible with operating systems other than Windows, it is hoped to provide execution environments for various operating systems to be compatible with their applications.
The subsystem is also called the Windows Environment Subsystem (Environment Subsystem).
Subsystems are essentially another middle layer that Windows assumes between APIs and applications.
It is very difficult for a subsystem to achieve binary level compatibility, so its goal is source code level compatibility, that is, to implement all interfaces of other operating systems.
But the Windows subsystem has actually been abandoned, everyone knows it.