IA64, PPC system call path audit patches

[Peter Chubb]

>>>>> "Robert" == Robert Watson <rwatson at FreeBSD.org> writes:

Robert> On Fri, 1 Sep 2006, Peter Chubb wrote:

>> You've only caught the IA64 slow path system call entries.  The
>> fast path is highly optimised assembly language inside
>> arch/ia64/kernel/fsys.S, that avoids doing a trap at all.
>> 
>> With a modern libc, syscall_via_break is only called for a very few
>> system calls.

Robert> Hmm.  I'm confused by the above comment -- I'm catching system
Robert> calls on the kernel side of the system call invocation around
Robert> the system call, not on the libc side.  I only see two system
Robert> call demux points in the src/sys/ia64 tree:

Sure.  Original libcs call the system call using break 0x10000, which
ends up in the code you saw.  Recent libcs call via a gate page with
an epc (execute privileged code) instruction that vectors direcgtly to
the syscall implementation.

Robert> ./ia32/ia32_trap.c: error = (*callp->sy_call)(td, args64);
Robert> ./ia64/trap.c: error = (*callp->sy_call)(td, args);

Take a look in gate.S, symbol _kernel_syscall_via_epc

There's assembly language there that loads the function descriptor
from the table and branches to it.  THere are two kinds of system call
implementations: fast (implemented directly in assembly language in
fsys.S) and slow (the code in fsys.S `bubbles down' into kernel space
and then invokes the syscall directly.

Robert> Both of which are covered in the patch I attached.  I'm under
Robert> the impression that the different mechanisms to enter the
Robert> kernel system call path converge prior to the system call
Robert> table evaluation, in the kernel trap code.  Do I
Robert> misunderstand?

Robert> Robert N M Watson Computer Laboratory University of Cambridge