October 2007 - Darwin-kernel

Launchd API documentation
by Todd Heberlein 16 Oct '07

16 Oct '07

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Is there *any* documentation for the launchd APIs? Any help would be appreciated, Todd _______________________________________________ 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.… There is a fair amount of documentation regarding the philosophy of Apple's launchd service and how to set up the .plist and where to place them, but I couldn't find a lot of (or any) documentation on when and how we should use the APIs in launch.h. The reason I ask is that I wrote a simple network service written in C ++ that reads in input from cin, writes the information back out cout, and appends the same information in a file. It makes no assumptions about how it is started (i.e., via command line or as a network service). Everything works fine. BUT when I added a getauid() or setauid() to get/set Audit IDs I get very strange results. I need to figure out if I am doing something wrong by *not* calling the launchd APIs, or is there something wrong with the audit APIs. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kext Load on demand and daemon communication
by Shaun Wexler 16 Oct '07

16 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 16, 2007, at 10:53 AM, Eric Long wrote: In order to listen to messages from the kext, the daemon creates a notification port, connects to the kext, and waits for available data. _______________________________________________ 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 I am looking to understand how load-on-demand drivers interact with daemons. I'm not an experienced driver writer, so I apologize in advance for missing the obvious. (-: I have a driver that sends messages to a daemon that is always running. The daemon has other purposes besides responding to messages from this kext. Since the daemon must connect to the kext to listen for messages from it, the kext must be loaded, so it seems there is no load on demand benefit, it just stays loaded. This seems like a Catch-22 to me. I don't want the kext to load unless the OS determines that it is needed, but if it is loaded, I need my daemon to listen to it. I can't listen to it without loading it. Can I listen for its loading, then listen for messages? What's the secret to making this work? When IOKit matches your device, your kext may call KUNCExecute() to launch the daemon if it's not already running. NOTE: KUNC is unsupported but available. Otherwise the daemon must remain running, to listen for service matching notifications, and unfortunately launchd does not provide this much-needed feature. -- Shaun Wexler MacFOH http://www.macfoh.com "No problem is so formidable that you can't walk away from it." - Charles Schulz smime.p7s

1 0

Kext Load on demand and daemon communication
by Eric Long 16 Oct '07

16 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcgQHXfLtnJD2nwQEdybcAAX8si2KA== Thread-topic: Kext Load on demand and daemon communication User-agent: Microsoft-Entourage/11.3.6.070618 Hi I am looking to understand how load-on-demand drivers interact with daemons. I'm not an experienced driver writer, so I apologize in advance for missing the obvious. (-: I have a driver that sends messages to a daemon that is always running. The daemon has other purposes besides responding to messages from this kext. In order to listen to messages from the kext, the daemon creates a notification port, connects to the kext, and waits for available data. Since the daemon must connect to the kext to listen for messages from it, the kext must be loaded, so it seems there is no load on demand benefit, it just stays loaded. This seems like a Catch-22 to me. I don't want the kext to load unless the OS determines that it is needed, but if it is loaded, I need my daemon to listen to it. I can't listen to it without loading it. Can I listen for its loading, then listen for messages? What's the secret to making this work? Thanks, Eric _______________________________________________ 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

IOInterruptEventSource in Leopard
by Boris Remizov 16 Oct '07

16 Oct '07

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=beta; h=domainkey-signature:received:received:message-id:from:to:content-type:mime-version:subject:date:x-mailer; bh=CVNErY27pgTgXcJPmZXlT8Upq091A2nrQ8/X0M7eT68=; b=NuJXEEncCEa8fDYfbP+YsAmSUf//ljmrRNoSuqcv+iHUzd/91QmVG7iUabpLk4xoY8HihCyaxjVRftmMRth1FdGV6Ie0u5RLznOuRBA1oNMpFtNrpC0LnFqAkZL3TOPXR8dFD4iEBBQM50F87RU+UnrxSYNnRvtxWIzdvLe7NaU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:from:to:content-type:mime-version:subject:date:x-mailer; b=TstfBDla51EWq5DLUh50SmuSlXJMORtcLXQ589M/r2eNkbYx7ZTShCivf9GQvS+/sUI4MGLQruoDMQ52TljaK6yLGZEX4P31SlC1NyUBMXNt0ggDY1Q0VdYx37rStyA8KJgfusatP3/H20rC2Odmv5rQfL2z9LzdWvGeg8BCQd4= _______________________________________________ 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: IOInterruptEventSource in Leopard
by Alexander von Below 16 Oct '07

16 Oct '07

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

Reading the version of a kext
by Régis Duchesne 15 Oct '07

15 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Icedove 1.5.0.9 (X11/20061220) Folks, Is there a way to read the version of a loaded kext from another kext? I'm trying to do what kextstat does (in userland) but from a kext: com.apple.iokit.IOHIDFamily (1.5) I would like to avoid having to do it in userland, then communicate the result to my kext. Thanks, -- hpreg _______________________________________________ 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: Kernel authorization (Kauth) from user space
by Liviu Andron 14 Oct '07

14 Oct '07

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=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hAGwX2+7pRwtKQkZlGYDX+OD5TtvbXZukjDANFCBHBE=; b=FMDLZAuO03RAsSBtDQo5dsbWTMQdvXk1soFqdPsnECG4bgpP1afE0tLs3WftuWcbIsH1LFKEQIKvPaw+FIl6rHboqUw0y5R5ncXOhaf6TswS+6mmoKcA15qwrU5nZG3gOUXDWRmuTNY1D0sUzR1sniG5OfnvPzQ/LA+mj007yA4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U65D543zD0Ef6A72ZaFHVx3gPat2IUUHFfPfUz+wkGi/P9c5qZB+zW/ffyXQs7wvRn/jOsAiy9adMNj19+AjumyWnl5QB/WQCddOQk2bkoxMPihqHF+e0vz2ydMse5ggKxZ4CSXhHDUYHR/BmYzysiq9yZVNJYzio7JB09f+ArI= On 10/13/07, Michael Smith <drivers(a)mu.org> wrote: > > On Oct 11, 2007, at 6:05 AM, Liviu Andron wrote: > > > I have some troubles in accessing files from user space using > > Kauth. Access means read or write. > > It is not clear from what you've written here exactly what you are > trying to do. > > I am going to assume that you have a KAUTH filter and a user-space > component that communicates with this filter. In the user-space > component, you want to read/write files that are being seen by the > filter. Correct. > > > 1) The recommended way from the technical documentation is to read/ > > write in kernel, but all the mailing lists discussions say to do it > > in user space. > > As per Terry, I am not aware of any documentation that suggests you > should be reading/writing files from within the kernel. It is highly > discouraged. Answered to Terry. > > > 2) Assuming that I send the path from kernel to the user space > > daemon (returned by vn_getpath from the vnode parameter) , I have > > the following issues: > > - for files with paths longer than MATXPAHTLEN (1024) , > > which can be created with Finder: > > - vn_getpath returns error 28 (KERN_INVALID_POLICY) > > - the callback for OPEN/CLOSE actions is called with > > empty path (arg1) or it's not called at all > > As has been noted, vn_getpath operates on an arbitrary buffer supplied > by the caller. If you make your buffer bigger on seeing this error, > you should be OK. > > Note that the close callback is only called for the last close on a > file. Thanks for the last tip, but it isn't what I intended to say. I'll try to post next days more information related to long paths. > > > 4) Another possible solution seems to be using VNOP_READ/ > > VNOP_WRITE in kernel space and transfer data to daemon > > This devolves to doing file I/O in the kernel again, which is still > highly discouraged. > > = Mike > > Look what I understand: implementing Kauth listeners (and I need both fileop and vnode listeners) with the need to read/write from/to files must be done by using the path in user space.( 1) no file I/O in kernel 2) no way to provide a file descriptor to the user space). Problems with the paths in user space: 1) maybe the path cannot be always retrieved 2) very long paths: technical problems when transferring them in user space (large memory allocations, IODataQueue needs a limit) (I just say it is difficult) ( anyway , the path isn't very interesting unlike reading/writing from/to files) 3) (?) a file descriptor might be impossible to obtain if the vnode is created with exclusive access ; wait for the last CLOSE ? what about a shutdown ? (the only way I see to avoid exclusivness is to read/write from the initial vnode, but that's kernel) I mentioned these problems in the second reply, first 2 can be avoided with a file descriptor retrieved from the vnode in kernel, which also can't be done. Thanks for the help. _______________________________________________ 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: Kernel authorization (Kauth) from user space
by Liviu Andron 14 Oct '07

14 Oct '07

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=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rhbZ85q0GIuCMakuVKIL76Uof5lAn7gvhyBBRXwBfyE=; b=s62MY/hBDi3UUMKwMlrpYztrxhrvPajBGMIspXQs6TzhxHPuiad18l6o/twsB3q+3vD45y+EFpLRyz1i9Qhg+L1kf+wmH87eNSxyN/v5XSuKCBWuW+NX5SfAwZnsBe2jDAMPeVjqLVQXSMY/hCNv62Op0aM4UO2vHDLue/kpw+k= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KENFJjExUhDAItJTaprKb3BOeXFz6H0K+pwmG2kpY6GjP6Q9RGRuOAaoUP5fJ5VXddGc3eGTD+UjjttaC4K2Sb0fDcAPClBXbUBJErB2KJBXBSzKu5zUKBFZkhlMeb9QFiDRZ9h4nMoRbQ6gSl8L38x9L+eWAtX0Gx+rmcKUp8Y= On 10/13/07, Terry Lambert <tlambert(a)apple.com> wrote: > On Oct 12, 2007, at 3:37 AM, Liviu Andron wrote: > > On 10/11/07, Jernej Azarija <Jernej.Azarija(a)hermes-softlab.com> wrote: > >>> 1) The recommended way from the technical documentation is to read/ > >>> write > >> in > >>> kernel, but all the mailing lists discussions say to do it in user > >>> space. > >> In userspace? It depends on what you need to accomplish. > > > > I need to read and/or write from/to files in both fileop scope and > > vnode scope listeners. > > > I'm actually unaware of any technical documentation from Apple that > recommends reading or writing files from within the kernel. If you > can point me at the documentation for this, I can grab the other > members of the CoreOS kernel team, and we can go beat the author up. > 8-). ADC Home > Reference Library > Technical Notes > Darwin > Kernel Technical Note TN2127 "Kernel Authorization" "In this case the only correct solution is for the scanner to operate entirely within the kernel." > >>> - for files with paths longer than MATXPAHTLEN (1024) , > >>> which can > >> be > >>> created with Finder: > >>> - vn_getpath returns error 28 (KERN_INVALID_POLICY) > >>> - the callback for OPEN/CLOSE actions is called with > >>> empty > >>> path (arg1) or it's not called at all > >> > >> Use the supplied path as said. You'll only have to play about > >> transfering > >> the path to userspace. > > > > In the vnode listener you have no path. Please read all the message. > > KERN_INVALID_POLICY is a Mach error return code that generally only > every gets seen when you attempt to select an unsupported scheduling > policy for a mach task or mach thread. > > vn_getpath() on the other hand is a BSD function that only returns the > result of a build_path(). Its possible return codes are: > > EINVAL > ENOENT > ENOSPC > > and the results of vnode_getattr() and of VFS_GET(). Since you are > seeing 28, you are seeing: > > #define ENOSPC 28 /* No space left on device */ > > ...which means that the buffer you have supplied to contain the path > information you are requesting is too small. Use a correctly sized > buffer, and the problem will go away. Most likely,you are only > reserving sufficient space for the terminal path component, rather > than the entire path to the file. > Sorry for the confusion, I should have imagined. I also did a little research ( http://fxr.watson.org/fxr/source/bsd/vfs/vfs_cache.c?v=xnu-792.6.70#L134) and now I understand. http://fxr.watson.org seems to be the best kernel documentation, it's not Darwin 8.10, but I think it is close enough since it includes kernel authorization. So I have to do something like "while (ENOSPC == err) { size *= 2; <allocate size (a lot of memory)>; err = vn_getpath(....); } > > >>> 4) Another possible solution seems to be using VNOP_READ/ > >>> VNOP_WRITE in > >>> kernel space and transfer data to daemon > >> > >> If you only need to hook open/close, use KAUTH_SCOPE_FILEOP. It's not > >> reasonable to hook VNODE operations - at last from the performance > >> view. > > > > I don't want to hook the operations, I want to use them for read or > > write from/to files. > > This is strongly discouraged, if you are talking about reading or > writing files from the kernel. Thanks for the answer. I don't need to try it then. > > -- 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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel authorization (Kauth) from user space
by Michael Smith 13 Oct '07

13 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 11, 2007, at 6:05 AM, Liviu Andron wrote: = Mike _______________________________________________ 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.… I have some troubles in accessing files from user space using Kauth. Access means read or write. It is not clear from what you've written here exactly what you are trying to do. I am going to assume that you have a KAUTH filter and a user-space component that communicates with this filter. In the user-space component, you want to read/write files that are being seen by the filter. 1) The recommended way from the technical documentation is to read/ write in kernel, but all the mailing lists discussions say to do it in user space. As per Terry, I am not aware of any documentation that suggests you should be reading/writing files from within the kernel. It is highly discouraged. 2) Assuming that I send the path from kernel to the user space daemon (returned by vn_getpath from the vnode parameter) , I have the following issues: - for files with paths longer than MATXPAHTLEN (1024) , which can be created with Finder: - vn_getpath returns error 28 (KERN_INVALID_POLICY) - the callback for OPEN/CLOSE actions is called with empty path (arg1) or it's not called at all As has been noted, vn_getpath operates on an arbitrary buffer supplied by the caller. If you make your buffer bigger on seeing this error, you should be OK. Note that the close callback is only called for the last close on a file. 4) Another possible solution seems to be using VNOP_READ/ VNOP_WRITE in kernel space and transfer data to daemon This devolves to doing file I/O in the kernel again, which is still highly discouraged. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel authorization (Kauth) from user space
by Terry Lambert 12 Oct '07

12 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I need to read and/or write from/to files in both fileop scope and vnode scope listeners. EINVAL ENOENT ENOSPC #define ENOSPC 28 /* No space left on device */ I don't want to hook the operations, I want to use them for read or write from/to files. -- 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 Oct 12, 2007, at 3:37 AM, Liviu Andron wrote: On 10/11/07, Jernej Azarija <Jernej.Azarija(a)hermes-softlab.com> wrote: 1) The recommended way from the technical documentation is to read/ write in kernel, but all the mailing lists discussions say to do it in user space. In userspace? It depends on what you need to accomplish. I'm actually unaware of any technical documentation from Apple that recommends reading or writing files from within the kernel. If you can point me at the documentation for this, I can grab the other members of the CoreOS kernel team, and we can go beat the author up. 8-). - for files with paths longer than MATXPAHTLEN (1024) , which can be created with Finder: - vn_getpath returns error 28 (KERN_INVALID_POLICY) - the callback for OPEN/CLOSE actions is called with empty path (arg1) or it's not called at all Use the supplied path as said. You'll only have to play about transfering the path to userspace. In the vnode listener you have no path. Please read all the message. KERN_INVALID_POLICY is a Mach error return code that generally only every gets seen when you attempt to select an unsupported scheduling policy for a mach task or mach thread. vn_getpath() on the other hand is a BSD function that only returns the result of a build_path(). Its possible return codes are: and the results of vnode_getattr() and of VFS_GET(). Since you are seeing 28, you are seeing: ...which means that the buffer you have supplied to contain the path information you are requesting is too small. Use a correctly sized buffer, and the problem will go away. Most likely,you are only reserving sufficient space for the terminal path component, rather than the entire path to the file. 4) Another possible solution seems to be using VNOP_READ/ VNOP_WRITE in kernel space and transfer data to daemon If you only need to hook open/close, use KAUTH_SCOPE_FILEOP. It's not reasonable to hook VNODE operations - at last from the performance view. This is strongly discouraged, if you are talking about reading or writing files from the kernel. This email sent to site_archiver(a)lists.apple.com

1 0