From owner-freebsd-hackers Wed Apr 3 23:13:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id D850A37B41E for ; Wed, 3 Apr 2002 23:13:05 -0800 (PST) Received: from pool0193.cvx40-bradley.dialup.earthlink.net ([216.244.42.193] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16t1QL-0007mO-00; Wed, 03 Apr 2002 23:12:45 -0800 Message-ID: <3CABFCCF.A18EB25D@mindspring.com> Date: Wed, 03 Apr 2002 23:12:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramkumar Chinchani Cc: Julian Elischer , "Tim J. Robbins" , freebsd-hackers@FreeBSD.ORG Subject: Re: Ptracing each other References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ramkumar Chinchani wrote: > ==> Terry Lambert /7:01pm/Apr 3, 2002 <== > [Ramkumar Chinchani wrote: > [> The requirement is that I have a theoretical framework where no process > [> trusts the other. So they watch (trace) each process. > [ > [Sure. > [ > [All you have to do is patch the OS to lie to you about not > [seeing trace events in a trace... > > How does make such a distinction inside the kernel? Is it possible to > identify trace events in a trace and just ignore them? I was being facetious. The only way to fix your program so that it doesn't crash and can reliably detect when a program that it doesn't trust has done something bad is to make the kernel itself untrustworthy. I suspect that that you really want it the ability to monitor calls made by another program, rather than intercepting those calls, and that you'd want to prevent monitoring calls from showing up in the monitored stream. This implies several things: 1) The interface you are trying to use is the wrong interface, because it operates in lockstep. 2) The operations need to be events, rather than the returns from calls. 3) The event stream needs to be decoupled from the event action stream, which implies that the events should be queued to any monitoring process. Given that, I'd suggest that you'd be better off replacing the interface with a monitoring interface based on KNOTE() for monitoring, but not intercepting events, as they happen, and then using kqueue()/kevent() in the monitoring process so that the calls and your reaction to them can be asynchronous. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message