From owner-freebsd-ia64@FreeBSD.ORG Fri Sep 1 10:02:56 2006 Return-Path: X-Original-To: ia64@FreeBSD.org Delivered-To: freebsd-ia64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3713416A4DD; Fri, 1 Sep 2006 10:02:56 +0000 (UTC) (envelope-from peterc@chubb.wattle.id.au) Received: from mx.chubb.wattle.id.au (mx.chubb.wattle.id.au [66.29.2.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E6743D58; Fri, 1 Sep 2006 10:02:54 +0000 (GMT) (envelope-from peterc@chubb.wattle.id.au) Received: from c220-237-8-57.randw1.nsw.optusnet.com.au ([220.237.8.57] helo=quokka.chubb.wattle.id.au) by mx.chubb.wattle.id.au with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1GJ5rP-0006RS-6y; Fri, 01 Sep 2006 20:02:53 +1000 Received: from localhost ([127.0.0.1] helo=quokka.chubb.wattle.id.au) by quokka with esmtp (Exim 4.63) (envelope-from ) id 1GJ5qv-0001gI-KY; Fri, 01 Sep 2006 20:02:21 +1000 Date: Fri, 01 Sep 2006 20:02:21 +1000 Message-ID: <87fyfbc3bm.wl%peterc@quokka.chubb.wattle.id.au> From: Peter Chubb To: Robert Watson 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> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijò) APEL/10.6 XEmacs/21.4 (patch 19) (Constant Variable) (i386-debian-linux) X-SA-Exim-Connect-IP: 220.237.8.57 X-SA-Exim-Rcpt-To: peterc@gelato.unsw.edu.au, rwatson@FreeBSD.org, ppc@FreeBSD.org, ia64@FreeBSD.org, marcel@FreeBSD.org X-SA-Exim-Mail-From: peterc@chubb.wattle.id.au X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mx.chubb.wattle.id.au X-Spam-Level: X-Spam-Status: No, score=-102.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_RFC_ABUSE,GREYLIST_ISWHITE,NO_DNS_FOR_FROM,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.1.4 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on mx.chubb.wattle.id.au) Cc: marcel@FreeBSD.org, ia64@FreeBSD.org, ppc@FreeBSD.org Subject: Re: IA64, PPC system call path audit patches X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 10:02:56 -0000 >>>>> "Robert" == Robert Watson writes: Robert> On Fri, 1 Sep 2006, Peter Chubb wrote: >>>>>>> "Robert" == Robert Watson 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