IBM 10 SP1 EAL4 manual System call argument verification, System p

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.2System 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.3System 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.4eServer 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.4System 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