site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Makes sense. Since the KEXT already depends on a daemon to filter the events, collecting the events using kqueue would require little extra effort, if it were reliable. But as Wade suggested, I'll just submit an enhancement request for process startup/exit notifications. In the mean time, I'd like to ask is this approach is correct: call proc_find(pid) which takes a reference to the proc_t, and then proc_rele(pid) when the exit notification from kqueue comes. This avoids the race, but will the process exit while I am holding a reference to it ? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jun 17, 2010, at 4:05 AM, Bogdan Harjoc wrote: On Thu, Jun 17, 2010 at 12:55 AM, Terry Lambert <tlambert@apple.com> wrote: On Jun 16, 2010, at 2:22 AM, Bogdan Harjoc wrote: Generally speaking, the kernel, including any KEXTs you write, exists to provide services for processes. Processes do not exist to provide notifications or events to the kernel. This is unlikely to happen, since the larger issue is that drivers live at the IOKit level, and while they can see BSD symbols, BSD can not see IOKit symbols in order to provide notifications to IOKit. Here is how symbol visibility works: User ------------------------------------------------------- ,-------------. ,-------------. ,-------------. Kernel | IOKit | | BSD | | MACH | `------------' | | | | ,--- | ---V-----' | | | | | | | | `--- | ------------------V--- ' | | ,----V---------------------- --' | | | `------------------------------------------ ' You're never going to get kevent notification in the kernel. If you take a proc reference, the proc exit will be delayed until you drop the reference. If you are taking the reference to prevent the process going away until after a kevent notification is delivered to user space about the process going away, it won't work: exit notification only happens on actual process exit, so as long as you hold a reference, you hold off the notification to user space. In addition, you have no guarantee that the locking order will happen the way you want it to, i.e. there is a race in acquiring the lock on the process list between you doing the pfind() and the process ID being reused between the time you decide a given PID is interesting to you and the time that the process reference is obtained on a process with that PID, such that it may not be the process you found interesting by the time you have the reference. It's undefined, which is why it's bad to use PID as a unique identifier for security purposes. The more correct model you should probably be looking at here is to report the activity up to a user space monitoring process, and have user space aggregate that activity with the process lifecycle events for the processes you are monitoring -- in other words, do your work in user space, and only do data gathering in kernel space. Bogdan This email sent to site_archiver@lists.apple.com