Linux system call table

This list is NOT READY and is under heavy construction, a lot of entries are missing, and some may be incorrect. This is more a template than a real document. Meanwhile, I suggest you to examine this list by H-Peter Recktenwald.

Table of Contents (template)

1. Introduction

2. System call in depth

3. Linux/i386 system calls

4. References

1. Introduction

First of all note that these are not libc «system calls», but real system calls provided by Linux Kernel.

List is intended to cover Linux 2.4 / 2.2 / 2.0.

2. System call in depth

3. Linux/i386 system calls

All system calls introduced/removed in specific Linux version are marked with (VER+/-) label (f.e. 2.2+ means that this call was introduced in Linux 2.2, and is missing in Linux 2.0). Square brackets hold real kernel name of system call from arch/i386/kernel/entry.S (as appeared in Syntax), if it differs from «official» in include/asm-i386/unistd.h.

Complete list of system calls with description

0. sys_setup

Syntax: int sys_setup(void)

Action: return -ENOSYS on Linux 2.2

Details: old sys_setup call

1. sys_exit

Syntax: int sys_exit(int status)

Action: terminate the current process

Details: status is return code

2. sys_fork

Syntax: int sys_fork()

Action: create a child process

3. sys_read

Syntax: ssize_t sys_read(unsigned int fd, char * buf, size_t count)

Action: read from a file descriptor

4. sys_write

Syntax: ssize_t sys_write(unsigned int fd, const char * buf, size_t count)

Action: write to a file descriptor

5. sys_open

Syntax: int sys_open(const char * filename, int flags, int mode)

Action: open and possibly create a file or device

6. sys_close

Syntax: sys_close(unsigned int fd)

Action: close a file descriptor

7. sys_waitpid

Syntax: int sys_waitpid(pid_t pid,unsigned int * stat_addr, int options)

Action: wait for process termination

8. sys_creat

Syntax: int sys_creat(const char * pathname, int mode)

Action: create a file or device

9. sys_link

Syntax: int sys_link(const char * oldname, const char * newname)

Action: make a new name for a file

10. sys_unlink

Syntax: int sys_unlink(const char * pathname)

Action: delete a name and possibly the file it refers to

11. sys_execve

Syntax: int sys_execve(struct pt_regs regs)

Action: execute program

12. sys_chdir

Syntax: int sys_chdir(const char * filename)

Action: change working directory

13. sys_time

Syntax: int sys_time(int * tloc)

Action: get time in seconds

14. sys_mknod

Syntax: int sys_mknod(const char * filename, int mode, dev_t dev)

Action: create a directory or special or ordinary file

15. sys_chmod

Syntax: int sys_chmod(const char * filename, mode_t mode)

Action: change permissions of a file

16. sys_lchown

Syntax: int sys_lchown(const char * filename, uid_t user, gid_t group)

Action: change ownership of a file

17. sys_break

Syntax: int sys_break()

Action: return -ENOSYS

Details: call exists only for compatibility

18. sys_oldstat

Syntax: int sys_stat(char * filename, struct __old_kernel_stat * statbuf)

19. sys_lseek

Syntax: off_t sys_lseek(unsigned int fd, off_t offset, unsigned int origin)

Action: reposition read/write file offset

20. sys_getpid

Syntax: int sys_getpid(void)

Action: get process identification

21. sys_mount

Syntax: int sys_mount(char * dev_name, char * dir_name, char * type, unsigned long new_flags, void * data)

Action: mount filesystems

22. sys_umount

Syntax: int sys_oldumount(char * name)

Action: unmount filesystem

23. sys_setuid

Syntax: int sys_setuid(uid_t uid)

Action: set user identity

24. sys_getuid

Syntax: int sys_getuid(void)

Action: get user identity

25. sys_stime

Syntax: int sys_stime(int * tptr)

Action: set time

26. sys_ptrace

Syntax: int sys_ptrace(long request, long pid, long addr, long data)

Action: process trace

27. sys_alarm

Syntax: unsigned int sys_alarm(unsigned int seconds)

Action: set an alarm clock for delivery of a signal

28. sys_oldfstat

Syntax: int sys_fstat(unsigned int fd, struct __old_kernel_stat * statbuf)

29. sys_pause

Syntax: int sys_pause(void)

Action: wait for signal

30. sys_utime

Syntax: int sys_utime(char * filename, struct utimbuf * times)

Action: change access and/or modification times of an inode

Источник

System Calls¶

Lecture objectives:¶

Linux system calls implementation
VDSO and virtual syscalls
Accessing user space from system calls

Linux system calls implementation¶

At a high level system calls are «services» offered by the kernel to user applications and they resemble library APIs in that they are described as a function call with a name, parameters and return value.

However, on a closer look, we can see that system calls are actually not function calls, but specific assembly instructions (architecture and kernel specific) that do the following:

setup information to identify the system call and its parameters
trigger a kernel mode switch
retrieve the result of the system call

In Linux, system calls are identified by numbers and the parameters for system calls are machine word sized (32 or 64 bit). There can be a maximum of 6 system call parameters. Both the system call number and the parameters are stored in certain registers.

For example, on 32bit x86 architecture, the system call identifier is stored in the EAX register, while parameters in registers EBX, ECX, EDX, ESI, EDI, EBP.

System libraries (e.g. libc) offers functions that implement the actual system calls in order to make it easier for applications to use them.

When a user to kernel mode transition occurs, the execution flow is interrupted and it is transfered to a kernel entry point. This is similar with how interrupts and exception are handled (in fact on some architectures this transition happens as a result of an exception).

The system call entry point will save registers (which contains values from user space, including system call number and system call parameters) on stack and then it will continue with executing the system call dispatcher.

During the user — kernel mode transition the stack is also switched from ther user stack to the kernel stack. This is explained in more details in the interrupts lecture.

The purpose of the system call dispatcher is to verify the system call number and run the kernel function associated with the system call.

To demonstrate the system call flow we are going to use the virtual machine setup, attach gdb to a running kernel, add a breakpoint to the dup2 system call and inspect the state.

In summary, this is what happens during a system call:

The application is setting up the system call number and parameters and it issues a trap instruction
The execution mode switches from user to kernel; the CPU switches to a kernel stack; the user stack and the return address to user space is saved on the kernel stack
The kernel entry point saves registers on the kernel stack
The system call dispatcher identifies the system call function and runs it
The user space registers are restored and execution is switched back to user (e.g. calling IRET)
The user space application resumes

System call table¶

The system call table is what the system call dispatcher uses to map system call numbers to kernel functions:

System call parameters handling¶

Handling system call parameters is tricky. Since these values are setup by user space, the kernel can not assume correctness and must always verify them throughly.

Pointers have a few important special cases that must be checked:

Never allow pointers to kernel-space
Check for invalid pointers

Since system calls are executed in kernel mode, they have access to kernel space and if pointers are not properly checked user applications might get read or write access to kernel space.

For example, lets consider the case where such a check is not made for the read or write system calls. If the user passes a kernel-space pointer to a write system call then it can get access to kernel data by later reading the file. If it passes a kernel-space pointer to a read system call then it can corrupt kernel memory.

Likewise, if a pointer passed by the application is invalid (e.g. unmapped, read-only for cases where it is used for writing), it could «crash» the kernel. There two approaches that could be used:

Check the pointer against the user address space before using it, or
Avoid checking the pointer and rely on the MMU to detect when the pointer is invalid and use the page fault handler to determine that the pointer was invalid

Although it sounds tempting, the second approach is not that easy to implement. The page fault handler uses the fault address (the address that was accessed), the faulting address (the address of the instruction that did the access) and information from the user address space to determine the cause:

Copy on write, demand paging, swapping: both the fault and faulting addresses are in user space; the fault address is valid (checked against the user address space)
Invalid pointer used in system call: the faulting address is in kernel space; the fault address is in user space and it is invalid
Kernel bug (kernel accesses invalid pointer): same as above

But in the last two cases we don’t have enough information to determine the cause of the fault.

In order to solve this issue Linux uses special APIs (e.g copy_to_user() ) to accesses user space that are specially crafted:

The exact instructions that access user space are recorded in a table (exception table)
When a page fault occurs the faulting address is checked against this table

Although the fault handling case may be more costly overall depending on the address space vs exception table size, and it is more complex, it is optimized for the common case and that is why it is preferred and used in Linux.

Cost	Pointer checks	Fault handling
Valid address	address space search	negligible
Invalid address	address space search	exception table search

Virtual Dynamic Shared Object (VDSO)¶

The VDSO mechanism was born out of the necessity of optimizing the system call implementation, in a way that does not impact libc with having to track the CPU capabilities in conjunction with the kernel version.

For example: x86 has two ways of issuing system calls: int 0x80 and sysenter. The later is significantly faster so it should be used when available. However, it is only available for processors newer than Pentium II and only for kernel versions greater than 2.6.

With VDSO the system call interface is decided by the kernel:

a stream of instructions to issue the system call is generated by the kernel in a special memory area (formatted as an ELF shared object)
that memory area is mapped towards the end of the user address space
libc searches for VDSO and if present will use it to issue the system call

An interesting development of the VDSO are the virtual system calls (vsyscalls) which run directly from user space. These vsyscalls are also part of VDSO and they are accessing data from the VDSO page that is either static or modified by the kernel in a separate read-write map of the VDSO page. Examples of system calls that can be implemented as vsyscalls are: getpid or gettimeofday.

«System calls» that run directly from user space, part of the VDSO
Static data (e.g. getpid())
Dynamic data update by the kernel a in RW map of the VDSO (e.g. gettimeofday(), time(), )

Accessing user space from system calls¶

As we mentioned earlier, user space must be accessed with special APIs ( get_user() , put_user() , copy_from_user() , copy_to_user() ) that check wether the pointer is in user space and also handle the fault if the pointer is invalid. In case of invalid pointers they return a non zero value.

Let’s examine the simplest API, get_user, as implemented for x86:

The implementation uses inline assembly, that allows inserting ASM sequences in C code and also handles access to / from variables in the ASM code.

Based on the type size of the x variable, one of __get_user_1, __get_user_2 or __get_user_4 will be called. Also, before executing the assembly call, ptr will be moved to the first register EAX while after the completion of assembly part the value of EAX will be moved to __ret_gu and the EDX register will be moved to __val_gu.

It is equivalent to the following pseudo code:

The __get_user_1 implementation for x86 is the following:

The first two statements check the pointer (which is stored in EDX) with the addr_limit field of the current task (process) descriptor to make sure that we don’t have a pointer to kernel space.

Then, SMAP is disabled, to allow access to user from kernel, and the access to user space is done with the instruction at the 1: label. EAX is then zeroed to mark success, SMAP is enabled, and the call returns.

The movzbl instruction is the one that does the access to user space and its address is captured with the 1: label and stored in a special section:

For each address that accesses user space we have an entry in the exception table, that is made up of: the faulting address(from), where to jump to in case of a fault, and a handler function (that implements the jump logic). All of these addresses are stored on 32bit in relative format to the exception table, so that they work for both 32 and 64 bit kernels.

All of the exception table entries are then collected in the __ex_table section by the linker script:

The section is guarded with __start___ex_table and __stop___ex_table symbols, so that it is easy to find the data from C code. This table is accessed by the fault handler:

All it does is to set the return address to the one in the to field of the exception table entry which, in case of the get_user exception table entry, is bad_get_user which return -EFAULT to the caller.

Источник