Re: Process exit notifcation in a kext
Re: Process exit notifcation in a kext
- Subject: Re: Process exit notifcation in a kext
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 16 Jun 2010 10:47:56 -0700
>> "Every process has a process identification number (PID) that is
>> assigned according to order it was run. The first process that runs
>> has a PID of 1. The second has a PID of 2 and so on. If a process dies
>> or is killed, that PID is not reused. If the computer is restarted,
>> the process count begins at 1 again."
This is wrong and has never been true. Mac OS X, like all BSDs, will recycle unused pids after wrapping at some predefined threshold.
> What I meant to say is that I read that document, but it's simply not
> true that PIDs aren't reused. You can verify this easily (the upper
> bound appears to be around 100,000):
That is more or less correct, it is 100,000 in Leopard and Snow Leopard. Though that includes pid 0, which symbolically means the kernel, so the highest pid actually available is 99,999.
In Tiger and earlier the limit was 30,001 (i.e. highest pid was 30,000).
> I assume what the document means is that PIDs aren't immediately
> reused when a process exits, but will be reused when the upper bound
> is hit. That's an implementation detail though, and I know Terry's
> mentioned before that PID randomization may happen eventually. So it's
> best to consider the potential race conditions, which it sounds like
> you've already been contemplating.
Pid reuse has been a problem on Mac OS X, even with the 100,000 ceiling. And you can imagine that in future it may be even moreso.
There is not really a good, simple substitute. If possible you should use Mach task ports, or task name ports, but those are't always an option. You need to decide if there is a security concern in your particular use, and mitigate that appropriately.
I also recommend filing radars and enhancement requests around this issue. Snow Leopard introduced unique IDs for threads, which had previously suffered from the same reuse issues, and it's trivial to imagine the same mechanism for processes.
You could also file an enhancement request for monitoring thread/task creation/destruction in the kernel. Such a thing would be useful to others, as well.
Wade
_______________________________________________
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