Date: Wed, 03 Apr 2002 23:12:15 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Ramkumar Chinchani <rc27@cse.Buffalo.EDU> Cc: Julian Elischer <julian@elischer.org>, "Tim J. Robbins" <tim@robbins.dropbear.id.au>, freebsd-hackers@FreeBSD.ORG Subject: Re: Ptracing each other Message-ID: <3CABFCCF.A18EB25D@mindspring.com> References: <Pine.SOL.4.30.0204040118330.19398-100000@tarantula.cse.Buffalo.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
Ramkumar Chinchani wrote: > ==> Terry Lambert <tlambert2@mindspring.com>/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CABFCCF.A18EB25D>