June 2010 - Darwin-kernel - lists.apple.com

Re: ptrace / task_for_pid / pid_suspend
by Michael Smith 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Antoine Missout 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Antoine Missout 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Wade Tregaskis 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Antoine Missout 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Wade Tregaskis 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com > 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 (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ptrace / task_for_pid / pid_suspend
by Michael Smith 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

ptrace / task_for_pid / pid_suspend
by Antoine Missout 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, We have a kernel driver + user-space daemon for a new product. Once loaded & running, the daemon becomes crucial to the proper running of the kernel: more exactly, the daemon can be running or not, but must not freeze as the kernel will deadlock while waiting for an answer. The setup is now very stable, the only issue we've run lately was with Instruments, using Time Profile for all process: this would result in an immediate lockup of the machine. Reading a bit of documentation about this probing, it seems Instruments suspends all process to take statistics. 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. This now allows for Instruments to Time Profile the whole machine without lockup the machine. We would prefer to take less drastic steps to avoid this deadlock, but without knowing what exactly is Instruments doing using our task port, this is difficult. It still seems to gather stats for the daemon, but the addresses look like garbage. So the questions are: - what is Instruments (or DTTSecD ?) doing exactly ? - is there a better way to make sure the daemon is never suspended in any way ? (or know it in advance ?) Thanks, Antoine _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: problem calling Mach RPC function
by Antoine Missout 30 Jun '10

30 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: kext version handling
by Luciano 24 Jun '10

24 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: KMail/1.9.5 On Wednesday 23 June 2010 17:33, Michael Smith wrote: > > You would normally expose a UserClient from your kext. Pick a constant > method index (0 is a fine choice) and have it return a version number. > > Alternatively, set a property on the device containing the version number; > you can do this passively by having the version number in the driver's > personality dictionary, where it can be filled in by Xcode at build time. > > = Mike > Hi Mike, thank you for you answer! But in my case the kext is not implemented by means of the IOKit. Its a pure C kext (I use it to intercept file accesses via Kauth) that communicates with userland by means of control sockets. So I guess I cant use the IOKit facilities, right? What possibilities exist for a kext written in C to expose its version number? Should I use the "Bundle version" number? And if so, how can I retrieve it from my userspace library? Thx for your help in advance! Best regards, Luciano _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0