Re: Process exit notifcation in a kext
Re: Process exit notifcation in a kext
- Subject: Re: Process exit notifcation in a kext
- From: Terry Lambert <email@hidden>
- Date: Thu, 17 Jun 2010 11:24:19 -0700
On Jun 17, 2010, at 4:05 AM, Bogdan Harjoc wrote:
On Thu, Jun 17, 2010 at 12:55 AM, Terry Lambert <email@hidden>
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.
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.
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---------------------- --' |
|
|
`------------------------------------------ '
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 ?
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.
-- Terry
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden