Date: Fri, 01 Sep 2006 20:02:21 +1000 From: Peter Chubb <peterc@gelato.unsw.edu.au> To: Robert Watson <rwatson@FreeBSD.org> 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: <87fyfbc3bm.wl%peterc@quokka.chubb.wattle.id.au> In-Reply-To: <20060901095744.Q4921@fledge.watson.org> 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> <20060901095744.Q4921@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Robert" == Robert Watson <rwatson@FreeBSD.org> writes: Robert> 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. Robert> As I read the epc_syscall code, it still passes through the Robert> kernel syscall() function, which is instrumented in the patch. Robert> Are you sure that the code does what you describe? My ia64 Robert> assembly reading skills are weak to non-existent, but the Robert> final branch in epc_syscall does seem to be to the C language Robert> syscall path. AAArrrrgg. Sorry, I'm looking at Linux source (where the syscall path is a *lot* more streamlined than the FreeBSD source). My bad, I'll go away and hide in a corner. Peter C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87fyfbc3bm.wl%peterc>