IA64, PPC system call path audit patches

[Robert Watson]

On Fri, 1 Sep 2006, Peter Chubb wrote:

>>>>>> "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.

As I read the epc_syscall code, it still passes through the kernel syscall() 
function, which is instrumented in the patch.  Are you sure that the code does 
what you describe?  My ia64 assembly reading skills are weak to non-existent, 
but the final branch in epc_syscall does seem to be to the C language syscall 
path.

Robert N M Watson
Computer Laboratory
University of Cambridge