Information Technology Reference
In-Depth Information
between the user program and the kernel. As we will see later, stubs are also
used to mediate procedure calls between computers in a distributed system.
The system call stubs are illustrated in Figure 2.12. The user program calls
the user stub in the normal way, oblivious to the fact the implementation of the
procedure is in fact in the kernel. The user stub calls the trap instruction. The
hardware transfers control to the kernel, vectoring to the system call handler.
The handler acts as a stub on the kernel side, calling the implementation of the
routine in the kernel. The return path follows the reverse sequence.
We illustrate the behavior of the user-level stub in Figure 2.13 for the x86.
For each system call, the operating system provides a library routine for that
system call. This library routine takes its arguments, reformats them according
to the calling convention defined by the operating system kernel, and executes
a trap instruction. When the kernel returns, the stub can return the result pro-
vided by the kernel. Of course, the user program need not use the library routine
| it is free to trap directly to the kernel; in turn, the kernel needs to protect
itself from misbehaving programs that do not format arguments correctly.
The system call calling convention is arbitrary, so here we pass arguments
on the user stack, with a code indicating the type of system call in the register
%eax
. The return value comes back in
%eax
so there is no work to do on the
return.
The
int
instruction operates as described earlier, saving the program counter,
stack pointer, and eflags on the kernel stack, before calling the system call han-
dler through the interrupt vector. Depending on the calling convention, the ker-
nel handler saves any additional registers that must be preserved across function
calls. It then examines the system call integer code in
%eax
, verifies that it is a
legal opcode, and calls the correct stub for that system call.
The kernel stub has four tasks:
Locate system call arguments. Unlike a regular procedure, the argu-
ments to a system call are stored in user memory. In the example code
above, they were stored on the process's user stack. Of course, the user
stack pointer could be corrupted! Even if it is valid, it is a virtual ad-
dress, not a physical address. Any address provided by a user program
to a system call must be checked (to verify it is a legal address within
the user domain) and converted to a physical address that the kernel can
use to access the memory. In the example above, the pointer to the string
representing the file name is stored on the stack, so both the stack address
must be (checked and) translated, and then the value of the string pointer
stored on the stack must be (checked and) translated.
Validate parameters. The operating system kernel must also protect
itself against malicious or accidental errors in the format or content of its
arguments. A file name will normally be a zero-terminated string, but
the kernel cannot trust the user code to always work correctly. The file
