Date: Fri, 1 Sep 2006 10:03:05 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Chubb <peterc@chubb.wattle.id.au> Cc: marcel@FreeBSD.org, ia64@FreeBSD.org, Peter Chubb <peterc@gelato.unsw.edu.au>, ppc@FreeBSD.org Subject: Re: IA64, PPC system call path audit patches Message-ID: <20060901095744.Q4921@fledge.watson.org> In-Reply-To: <87hczsasl5.wl%peterc@quokka.chubb.wattle.id.au> References: <20060901080402.W97485@fledge.watson.org> <87irk8at9i.wl%peterc@quokka.chubb.wattle.id.au> <20060901092636.E4921@fledge.watson.org> <87hczsasl5.wl%peterc@quokka.chubb.wattle.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Sep 2006, Peter Chubb wrote: >>>>>> "Robert" == Robert Watson <rwatson@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060901095744.Q4921>