Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 13: System Calls


In addition, theLinux security modulessubsystem (LSM) provides a general interface to support
modules whose functions are invoked at varioushooks in the kernel to perform security checks:
❑ capsetandcapgetare responsible for setting and querying process capabilities.
❑ securityis a system call multiplexer for implementing LSM.

13.3 Implementation of System Calls


In the implementation of system calls, not only the kernel source code that provides the required func-
tions is relevant but also thewayin which the functions are invoked. Functions are not called in the same
way as normal C functions because the boundary between user and kernel mode is crossed. This raises
various problems that are handled by platform-specific assembly language code. This code establishes
a processor-independent state as quickly as possible to enable system calls to be implemented indepen-
dently of the underlying architecture. How parameters are passed between userspace and kernel space
must also be considered.

13.3.1 Structure of System Calls


Kernel code for implementing system calls is divided into two very different parts. The actual task to
be performed by the system call is implemented as a C routine that is virtually no different from the
remaining kernel code. The mechanism for calling the routine is packed with platform-specific features
and must take numerous details into consideration — so that ultimately implementation in assembly
language code is a must.

Implementationof HandlerFunctions


Let us first take a close look at what’s behind C implementation of the actual handler functions. These
functions are spread across the kernel because theyare embedded in code sections to which they are most
closely related in terms of their purpose. For example, all file-related system calls reside in thefs/kernel
subdirectory because they interact directly with the virtual filesystem. Likewise, all memory management
calls reside in the files of themm/subdirectory.

The handler functions for implementing system calls share several formal features:

❑ The name of each function is prefixed withsys_to uniquely identify the function as a system
call — or to be more accurate, as a handler function for a system call. Generally, it is not neces-
sary to distinguish between handler function and system call. In the sections below, I do so only
where necessary.
❑ All handler functions accept a maximum of five parameters; these are specified in a parameter
list as in normal C functions (how parameters are supplied with values differs slightly from the
classic approach, as you will see shortly).
❑ All system calls are executed in kernel mode. Consequently, the restrictions discussed in
Chapter 2 apply, primarily that direct accessto user mode memory is not permitted. Recall
thatcopy_from_user,copy_to_user, or other functions from this family must ensure that the
desired memory region is available to the kernel before doing the actual read/write operation.

Once the kernel has transferred control to the handler routine, it returns to completely neutral code that is
not dependent on a particular CPU or architecture. However, there are exceptions — for various reasons,
Free download pdf