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

Re: Process exit notifcation in a kext
by Terry Lambert 17 Jun '10

17 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User --------------------------------------------------------- ,-------------. ,-------------. ,-------------. Kernel | IOKit | | BSD | | MACH | `------------' | | | | ,--- | ---V-----' | | | | | | | | `--- | ------------------V--- ' | | ,----V--------------------------' | | | `---------------------------------------------' -- Terry _______________________________________________ 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.… Grrrrrr.... the default font in my composition window changed to be proportional instead of fixed width. The following will work in a "Terminal" window as a diagram; just cat > /dev/null and then paste it in: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Process exit notifcation in a kext
by Terry Lambert 17 Jun '10

17 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Jun 17, 2010, at 4:05 AM, Bogdan Harjoc wrote: On Thu, Jun 17, 2010 at 12:55 AM, Terry Lambert <tlambert(a)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(a)lists.apple.com

1 0

Re: Process exit notifcation in a kext
by Michael Smith 17 Jun '10

17 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: Process exit notifcation in a kext
by Bogdan Harjoc 17 Jun '10

17 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rmneec6sx4j3WHg/0xJwQEbJUX2MtcYGaeMdwWvgCt4=; b=CF66Rf5sAV4iMhzpoG8nSglb6nJbB/+cEmIvffH8HfiXMEiYHE5BBIiFLNI0Wo30Uu L4e0OgxvmMoS1bQJt6S7Eb40JQv0ly8loQWVgWIZOm4itfKiJ03Ket3zyUCmjw3zjS1Q TPwYkhNsVqklsMIe63gP+ToMNHLjNxMpOGus4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aSdP9G+dbYzzldUinSRBz5xXhNi7V5ylCwoI1SFS2qM9CXn49qO+9Jsyyzek/nwUda 7WUFzoXuMP2lq467URHu4F6s+L6fhfUIIWL6cj149Yex3Njgt/H2IRr1XC5XVeik2wZV gG2r1+Bn+Q7qtviqk6eZK2DAen4+JxFKkmnB4= On Thu, Jun 17, 2010 at 12:55 AM, Terry Lambert <tlambert(a)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. 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 ? > 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 (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: kextload failure on 10.5
by Chris Suter 17 Jun '10

17 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, On Thu, Jun 17, 2010 at 10:18 AM, Terry Lambert <tlambert(a)apple.com> wrote: >> Or user_addr_t and CAST_USER_ADDR_T perhaps? > > That's not a user space visible type or cast macro. You'd treat it like > that in the kernel, however. Are you sure? I seem to be able to get it via sys/types.h. > So the size of the structure is a component of the manifest constant used to > make the ioctl. If the structure size is variant because an element in the > structure is variant, then the command code is variant. Ah, I understand what you meant now. Kind regards, Chris _______________________________________________ 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: kextload failure on 10.5
by Terry Lambert 17 Jun '10

17 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, Is that right? The command value appears to be 32 bit regardless of architecture. We use an ioctl in our code and don't use different command values and it appears to work. (We obviously take care of the parameters.) Or am I misunderstanding what you're saying? You're misunderstanding. Here is how commands are assembled: -- Terry _______________________________________________ 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.… On Jun 16, 2010, at 4:34 PM, Chris Suter wrote: On Thu, Jun 17, 2010 at 8:15 AM, Terry Lambert <tlambert(a)apple.com> wrote: For example, if you needed to pass a pointer, you would declare the field as a uint64_t (unsigned long long), cat the pointer to a uintptr_t, and then Or user_addr_t and CAST_USER_ADDR_T perhaps? That's not a user space visible type or cast macro. You'd treat it like that in the kernel, however. PS: This goes for things like ioctl(2) parameters, as well; if they are size variant, you will find yourself implementing separate 32 and 64 bit versions of the ioctl(2) command value in the kernel so that you can deal with both 32 and 64 bit clients; otherwise, the ioctl(2) case statement number will not match, and it will look like it's an unrecognized ioctl(2) when you call it from a binary of the "wrong" bitness. #define IOCPARM_MAX (IOCPARM_MASK + 1) /* max size of ioctl args */ ... #define IOC_OUT (unsigned long)0x40000000 ... #define _IOC(inout,group,num,len) \ (inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num)) ... #define _IOR(g,n,t) _IOC(IOC_OUT, (g), (n), sizeof(t)) ... #define TIOCGETA _IOR('t', 19, struct termios) /* get termios struct */ So the size of the structure is a component of the manifest constant used to make the ioctl. If the structure size is variant because an element in the structure is variant, then the command code is variant. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kextload failure on 10.5
by Chris Suter 16 Jun '10

16 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, On Thu, Jun 17, 2010 at 8:15 AM, Terry Lambert <tlambert(a)apple.com> wrote: > For example, if you needed to pass a pointer, you would declare the field as > a uint64_t (unsigned long long), cat the pointer to a uintptr_t, and then Or user_addr_t and CAST_USER_ADDR_T perhaps? > PS: This goes for things like ioctl(2) parameters, as well; if they are size > variant, you will find yourself implementing separate 32 and 64 bit versions > of the ioctl(2) command value in the kernel so that you can deal with both > 32 and 64 bit clients; otherwise, the ioctl(2) case statement number will > not match, and it will look like it's an unrecognized ioctl(2) when you call > it from a binary of the "wrong" bitness. Is that right? The command value appears to be 32 bit regardless of architecture. We use an ioctl in our code and don't use different command values and it appears to work. (We obviously take care of the parameters.) Or am I misunderstanding what you're saying? Kind regards, Chris _______________________________________________ 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: kextload failure on 10.5
by Terry Lambert 16 Jun '10

16 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry _______________________________________________ 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.… On Jun 16, 2010, at 12:22 PM, mogambo wrote: I am running into another problem while trying to build a universal kext pkg for a vfs pIugin. I was able to create (lipo separate kext binaries) a universal binary for the kext that can run on ppc, i386 and x86_64. I also created a universal binary for the mount program similarly. The mount program compile cmdlines for i386 and ppc architectures both have "-isysroot $(SDKROOT10_4) -mmacosx-version-min=10.4", and the 64-bit version has "-isysroot $(SDKROOT10_6) -mmacosx-version- min=10.6". However, when I try to run the mount program on Leopard, it tries to run the 64-bit version and mount() returns EFAULT. I can understand that a 64-bit mount program cannot work with a 32-bit kernel extension. The size of mount_data structure, the size of variables and alignment are all going to be different between the two. Tracing the kext mount function, I see that it is not even getting called before the error is returned. Is there a way to force what arch to run in a universal binary? How does this work even when the mount program is created with xcode? There is the "arch" command, but it will probably not be satisfactory to you. XCode can force the running of the specific architecture of binary for testing purposes; in order to do this, it it uses an Apple extension to the posix_spawn(2) implementation, which is documented in the man pages. However, this will also likely not be satisfatory to you. The kernel, if it is capable of running 64 bit binaries, will *always* preferentially run the 64 bit binaries rather than the 32 bit binaries. There's no way to say "I want to run 32 bit on Leopard, and 64 bit on SnowLeopard". There's also no way to say "I want to run whatever bitness the kernel is currently running". The reasons for this are several, but the primary one is that the machine architecture and the 32/64 bitness of a binary are unrelated, since machines are capable of running 32/64 on either 32 or 64 bit kernels. Preference in user space generally comes down to plug-ins rather than kernel (e.g. you might have a 32 bit Safari plugin that has not been ported to 64 bits yet, and so you need to run Safari 32 bit to use the plugin, etc.). Several programs do a lot of pig-tricks, which you could do as well; however, I would not recommend them. The #1 pig trick is to decide what architecture you "should have been run as" after you are already running as the "wrong" architecture, and reexec yourself via posix_spawn(2) with the Apple-extension to pick the slice of the binary, coupled with the Apple extension to make posix_spawn(2) act like exec, rather than fork+exec. The flag is also documented in the manual pages. The *most correct* way to deal with this is to use sized types in the data structures you use to communicate between the kernel and user space, and ensure that the packing doesn't change (either by ordering larger structure elements first in the structure, or by using #pragma pack(4) / structure declaration / #pragma pack() or similar element packing controls). For example, if you needed to pass a pointer, you would declare the field as a uint64_t (unsigned long long), cat the pointer to a uintptr_t, and then assign it into the field. You would never use a "long" or a pointer type as an element type in a field, and so on. If the structure size is invariant between the kernel and user space, it's not going to matter if you are using a 32 bit or 64 bit client to talk to a 32 bit or 64 bit kernel. PS: This goes for things like ioctl(2) parameters, as well; if they are size variant, you will find yourself implementing separate 32 and 64 bit versions of the ioctl(2) command value in the kernel so that you can deal with both 32 and 64 bit clients; otherwise, the ioctl(2) case statement number will not match, and it will look like it's an unrecognized ioctl(2) when you call it from a binary of the "wrong" bitness. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Process exit notifcation in a kext
by Terry Lambert 16 Jun '10

16 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry _______________________________________________ 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.… On Jun 16, 2010, at 2:22 AM, Bogdan Harjoc wrote: I'm writing a kext that monitors processes based on their network traffic. One of the events I have to monitor is "process has exited". Kqueue offers a nice uniform way of doing this, but I don't see how it can be called from kernel code. My question is if kqueue can deliver events to a kext, or at least if one can start a kernel thread just for the purpose of waiting for events by calling kevent(). 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. There are a small number of exceptions to this; in almost every case, they involve a risk of deadlock and/or blocking the kernel waiting for the process which is waiting for the kernel, which is blocked by the process. For this reason, the code paths are limited, and the processes involved in servicing the request generally run as root in order to be immune to triggering operations to themselves. The general utility in these cases is authorization requests for things like Antivirus software or directory services providing group membership information and/or translation between uid/gid values and UUIDs to store or retrieve values stores in the filesec_t structure used to implement ACLs in the extended attributes in the HFS+ file system. 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kextload failure on 10.5
by mogambo 16 Jun '10

16 Jun '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=/JIh89AAy0V12VSrBjZseDM+jE7CQkqRBFduMhUfgmw=; b=XnUMRwAJnleMfKkcO30LAmYMSpr/UoNF+rtsYdmrnP5E/aszdg7ZRJrcGa+dYuI9Z3 yANa3JHkP6C24fXLWil0YZTsj4NQnOwOMF1GpIB13wY1EHxqYUpi7N9RuadNFmvWwxlu xqfDRF2PVwJOP3kHS0uU8AAXkuBMPh5/JrQkk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ciaYu9zkJIt0ji6tigf+8gci0xQP3jjmWWFnIJpyZ1bFd2S+wSdDA5k/TJlTXWaHkK QwT1M/Vau4EUdcCvIAZL9jYQI3VoxWHKzR0hXVjofnpFuJjwignpRUBDlmyZRDluhm24 FrrbgAxTIXs2qg8WMa66CU7UCY1/G87YNkX58= _______________________________________________ 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