Re: ptrace / task_for_pid / pid_suspend
Re: ptrace / task_for_pid / pid_suspend
- Subject: Re: ptrace / task_for_pid / pid_suspend
- From: Antoine Missout <email@hidden>
- Date: Wed, 30 Jun 2010 14:54:04 -0400
Hi Wade,
We plan to only allow our product to run on a specific version of macos x.
We will test and release an update for each os update from Apple.
Doing a diff on the xnu source code makes it easy to spot changes.
As for dtrace, PT_DENY_ATTACH sets P_LNOATTACH in the proc, and that effectively prevent dtrace probing our process (grep the xnu codebase for P_LNOATTACH).
Regarding denying task_for_pid, the mac framework (seatbelt/sandbox) already allows for that to be denied: the profiling tools should do proper error handling.
I do agree however, that using an appropriate timeout and log an error is the way to go for the released product (the kernel should never wait more than a few microseconds in normal usage). In the meantime, a full machine deadlock is a quite motivating way to fix the problem :D
If our daemon is suspended, any network or file access will probably block. I'm guessing Instruments suspend all processes, gather stats, writes them to a file, then resume all processes. If so, it will block while trying to save the stats. I guess we could also double-check in the kernel if the daemon is currently suspended and not try to communicate with it in that case.
We have means of white carding critical processes (such as the dynamic_pager / launchd / etc), so they never trigger communication between the kernel and user-space (ie no deadlocks because of pagefaults).
Regards,
Antoine
On 2010-06-30, at 2:07 PM, Wade Tregaskis wrote:
>> Now to avoid this problem, we've taken step to disable ptrace(PT_DENY_ATTACH), task_for_pid for our daemon, and while we're at it, also pid_suspend introduced in 10.6.4.
>
> If you subvert these mechanisms you will almost certainly break profiling tools and may cause other panics.
>
> In future your process may be suspended by other means anyway, so your solution isn't future-proof.
>
>> - what is Instruments (or DTTSecD ?) doing exactly ?
>
> Whatever it wants. You should consider that any old DTrace script could also do all sorts of things with your app which would similarly run afoul of it. The bottom line is that you can't prevent a userspace thread from being interrupted, suspended or otherwise manipulated.
>
>> - is there a better way to make sure the daemon is never suspended in any way ? (or know it in advance ?)
>
> Don't rely on userspace being available. Use an appropriate timeout or other failsafes that will prevent deadlock.
>
> If you'd like to detail how exactly you're deadlocking, I may be able to find you a better alternative.
>
> 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