system initialization, and sets the IDT entry corresponding to vector 128 (Ox80) to invoke the system call
exception handler.
When compiling and linking a program that makes a system call, the libc library wrapper routine for that
system call stores the appropriate system call number in the eax register, and executes the int 0x80 assembly
language instruction to generate the hardware exception. The exception handler in the kernel for this vector is
the system_call() system call handler. system_call() saves the contents of registers in the kernel-
mode stack, handles the call by invoking a corresponding C function in the kernel, and exits the handler by
means of the ret_from_sys_call() function.

5.16.3.2 System p

On System p systems, the PowerPC and POWER architecture provides the assembly instruction supervisor
call (SC) to make a system call. The kernel also uses the sc instruction to make hypervisor calls when the
SLES system is running in a logical partition. The processor distinguishes between hypervisor calls and
system calls by examining the general purpose register 0 (GPR0).
If the GPR0 contains -1, and the processor is in privileged state, then the sc instruction is treated as a
hypervisor call. Otherwise, it is treated as a system call request from user space. The sc instruction without
-1 in GPR0 generates an exception. The exception handler in the kernel redirects the call to the
system_call() system call handler. system_call() saves the contents of registers in the kernel
mode stack, handles the call by invoking a corresponding C function in the kernel, and exits the handler by
means of the ret_from_sys_call() function.

5.16.3.3 System z

On System z, z/Architecture provides the SuperVisor Call assembly instruction SVC() to make a system call.
The SVC instruction generates an exception. The exception handler in the kernel redirects the call to the
system call handler, system_call(). system_call() saves the contents of registers in the kernel
mode stack, handles the call by invoking a corresponding C function in the kernel, and exits the handler by
means of the ret_from_sys_call() function.

5.16.3.4 eServer 326

The AMD Opteron processors differ significantly from x86 architecture with respect to the entry point into
the kernel. The Opteron processor provides the SYSCALL and SYSRET special instructions instead of using
the interrupt 0x80. The SYSCALL assembly instruction performs a call to the system_call() system call
handler running at CPL level 0.
The address of the target procedure is specified implicitly through Model Specific Registers (MSRs).
system_call() saves the contents of registers in the kernel mode stack, handles the call by invoking a
corresponding C function in the kernel, and executes the SYSRET privileged instruction to return control back
to the user space.
5.16.4 System call argument verification
The process of transferring control from user mode to kernel mode does not generate any user-accessible
objects; thus, there are no object reuse issues to handle. However, because system calls often require input
parameters, which may consist of addresses in the address space of the user-mode process, an illegal access
violation can occur as a result of a bad parameter. For example, a user-mode process might pass an address
belonging to the kernel-address space as a parameter, and because the kernel routines are able to address all
pages present in memory, the address is able to read or write any page present in the memory without causing
a page fault exception. The SLES kernel prevents these kinds of access violations by validating addresses
216