May 2002 - Darwin-kernel - lists.apple.com

Re: IORegistry crash (was: Two IOService in the same kext ? )
by Godfrey van der Linden 30 May '02

30 May '02

Ok then, a few things. 1> The IOProviderClass of the framebuffer MUST be the same as the IOClass of the EffectDriver, i.e. it is case sensitive. 2> You probabably don't need to have IOPCIMatch in your IOFrameBuffer personality. 3> Does your effect driver call 'registerService()' on itself? If I read these personalities correctly you wish to create a 'driver' stack on top of your 'EffectDriver'. The EffectDriver gets loaded when it identifies your hardware on the IOPCIDevice nub. Then at start time you want the Effect driver to load the relevant FrameBuffer driver. You achieve this by two steps. First setup a personality for the Framebuffer with a provider class of your EffectDriver real class name (I usually copy and paste). Then call at starttime have com_matrox_driver_Effects::start(provider) call registerService() just before returning. Godfrey At 14:18 -0400 02-5-30, Francis bouchard wrote: can we see the IOKitPersonalties? IOFrameBuffer: CFBundleIdentifier com.matrox.driver.Display IOClass com_matrox_driver_Display IOMatchCategory IOFrameBuffer (I don't know what IOMatch is for actually... Taken from sample) IOPCIMatch 0x... (our hadware) (this works for sure) IOProviderClass com_matrox_driver_effects EffectDriver CFBundleIdentifier com.matrox.driver.Effects IOClass com_matrox_driver_Effects IOMatchCategory Something (I don't know what IOMatch is for actually... Taken from sample) IOPCIMatch 0x... (our hadware) (this works for sure) IOProviderClass IOPCIDevice IOUserClientClass com_matrox_driver_EffectsUserClient On 30/05/02 14:06, "Godfrey van der Linden" <gvdl(a)apple.com> wrote: It depends on how you publish your com_matrox_EffectDriver (Note the prefix, this is really important quite a few drivers are going to have effects right?) No. one dirver handles all the effects needs (the different effects are done in userland... (KEEP OUT of the kernel!) How does the 'Effect Driver' get created? Buy the OS ??? At boot time. How does your FrameBuffer get created? Buy the OS ???. At boot time. Theses are in /System/Library/Extensions Thanks a lot for taking time Francis _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: IORegistry crash (was: Two IOService in the same kext ? )
by Godfrey van der Linden 30 May '02

30 May '02

It depends on how you publish your com_matrox_EffectDriver (Note the prefix, this is really important quite a few drivers are going to have effects right?) How does the 'Effect Driver' get created? How does your FrameBuffer get created? can we see the IOKitPersonalties? Godfrey At 13:24 -0400 02-5-30, Francis bouchard wrote: Sorry for cross posting but I am really desperate. For the one who followed this thread, here is the status. I would like my driver model to look like the drawing. My IOFrameBuffer declares an IOProvicerClass of EffectDriver (which its provider is an IOPCIDevice). This way My effectDriver which is a service provider for my FrameBuffer gets loaded before the IOFrameBuffer and the FrameBuffer gets the pointer to the EffectDriver (its provider through the parameter in the start routine. But it doesn't work! HELP!!!! How do I make a driver a provider for another class ??? If I put the IOProviderClass in the bundle settings, my driver won load (kmod but no init called). A hint is that ioreg or IORegistry crashes! for some reason, as soos as I try to connect my IOFrameBuffer ot the effect dirver I seem to break everything up. If I put IOPCIDevice in the IOProviderClass and "slmost stub my frame buffer" everything is OK. Francis On 28/05/02 12:52, "Francis bouchard" <francis.bouchard(a)matrox.com> wrote: I agree that I'm more fighting with IOKit than using it. Let's see how my drivers works. Let's try ou my _talent_ for drawing. ------ ------------------ | OS | | our effects | User Land ------ ------------------ ________________|____________________________|_________ KernelLand | | ------------------- ------------------ | IOFBUserClient | | EffectDriver | | IOFrameBuffer | | UserClient | ------------------- ------------------ | | | ------------------ |_______________________| EffectDriver | | (IOService) | ------------------ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

IORegistry crash (was: Two IOService in the same kext ? )
by Francis bouchard 30 May '02

30 May '02

Sorry for cross posting but I am really desperate. For the one who followed this thread, here is the status. I would like my driver model to look like the drawing. My IOFrameBuffer declares an IOProvicerClass of EffectDriver (which its provider is an IOPCIDevice). This way My effectDriver which is a service provider for my FrameBuffer gets loaded before the IOFrameBuffer and the FrameBuffer gets the pointer to the EffectDriver (its provider through the parameter in the start routine. But it doesn't work! HELP!!!! How do I make a driver a provider for another class ??? If I put the IOProviderClass in the bundle settings, my driver won load (kmod but no init called). A hint is that ioreg or IORegistry crashes! for some reason, as soos as I try to connect my IOFrameBuffer ot the effect dirver I seem to break everything up. If I put IOPCIDevice in the IOProviderClass and "slmost stub my frame buffer" everything is OK. Francis On 28/05/02 12:52, "Francis bouchard" <francis.bouchard(a)matrox.com> wrote: > I agree that I'm more fighting with IOKit than using it. Let's see how my > drivers works. Let's try ou my _talent_ for drawing. > ------ ------------------ > | OS | | our effects | > User Land ------ ------------------ > ________________|____________________________|_________ > KernelLand | | > ------------------- ------------------ > | IOFBUserClient | | EffectDriver | > | IOFrameBuffer | | UserClient | > ------------------- ------------------ > | | > | ------------------ > |_______________________| EffectDriver | > | (IOService) | > ------------------ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Problem with the privileges of the KEXT package...
by Pelle Johansson 30 May '02

30 May '02

onsdagen den 29 maj 2002 kl 18.05 skrev Dean Reece: On Wednesday, May 29, 2002, at 03:55 AM, Stiphane Sudre wrote: On Wednesday, May 29, 2002, at 09:17 AM, Kevin Van Vechten wrote: Moreover than making the KEXT inaccessible to the group, it probably should not be in /Library/, since that is (and should be) group writable, limiting the effectiveness of any permissions to the KEXT. A purist such as myself would contend that KEXTs belong in /System/Library/Extensions, owned by root:wheel. The KEXT system was designed to load KEXTs from anywhere as long as their ownership & permissions were acceptable. If /Library/ is made sticky, and then Extensions set 755, it could reasonably be said that /Library/Extensions/ has strict enough privileges, without impeding too much on the usability. Is this something you have considered? You would still need to be root to install/remove KEXTs of course, but at least they won't be in /System/. -- Pelle Johansson <morth(a)morth.nu> _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: overloading system calls
by Jim Magee 29 May '02

29 May '02

On Wednesday, May 29, 2002, at 06:27 PM, Andrew Gallatin wrote: Is it possible for a kext to overload system calls (or Mach traps) in Darwin? Is there any example code for doing this available? No, and I hope not, in that order! ;-) In fact the first part is not true. Almost all Mach calls are just messages to a port. Strategically override which port gets returned (and Mach provides facilities for this in many of the interesting cases), and you can interpose on all the calls. In this particular case, you could override which port gets returned by mach_task_self() via task_set_special_port(), and override all Task, Mach port, and VM operations to filter out the ones you want. But that's an awful lot of work for what you are trying to do. I have another module (an IOKit driver) which wires memory for OS-bypass communications for unbounded amounts of time. If the user-level application misbehaves and attempts to free this wired memory prior to unwiring it, the VM system blocks in vm_deallocate() waiting for the memory to be unwired. The IOKit driver has no idea the VM system wants the memory to be unwired. Deadlock ensues. There are two variants of the wiring calls allowed by Mach. One which keeps the pages in memory as long as they are mapped, but allows the mappings to be removed. Another keeps everything where it is because I/O is active. We shouldn't be doing the latter except when DMAs are active. You can use both on the same memory at the same time. If the former is already in place, the latter is quite efficient (just bumps up reference counts and removes them when the DMA wiring is removed). I think you just have to get the right mix. So I'd like to snoop vm_deallocate() calls & catch those which attempt free memory that the IOKit driver has wired down so that I can get the driver to unwire the memory (and do the required cleanup so that no more DMAs happen to that region, of course). What would be ideal would be an optional callback in the vm_map_entry_t that could be called in vm_map_delete(), so that the VM system can request that the memory be unwired & not simply deadlock. Callbacks are powerful, but dangerous, and very difficult to get right. For something like this, a more active approach where the DMA wirings are removed after the DMA is a more reasoned approach. This is true unless there is some reason you can't tell when the DMAs end. But then I would argue that is a problem with you user client model. We explicitly order port destructions before memory destructions on task death for just this very reason. When the port which represents the user client goes away, the reference on the driver goes away and that should un-wire the memory so that the vm_deallocate() calls to follow make forward progress. The same should work for explicit shutdown as well (you can't deallocate the memory until you close the device if the device is going to place a persistent hold on the memory). --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

overloading system calls
by Andrew Gallatin 29 May '02

29 May '02

Is it possible for a kext to overload system calls (or Mach traps) in Darwin? Is there any example code for doing this available? I have another module (an IOKit driver) which wires memory for OS-bypass communications for unbounded amounts of time. If the user-level application misbehaves and attempts to free this wired memory prior to unwiring it, the VM system blocks in vm_deallocate() waiting for the memory to be unwired. The IOKit driver has no idea the VM system wants the memory to be unwired. Deadlock ensues. So I'd like to snoop vm_deallocate() calls & catch those which attempt free memory that the IOKit driver has wired down so that I can get the driver to unwire the memory (and do the required cleanup so that no more DMAs happen to that region, of course). What would be ideal would be an optional callback in the vm_map_entry_t that could be called in vm_map_delete(), so that the VM system can request that the memory be unwired & not simply deadlock. Thanks, Drew _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Problem with the privileges of the KEXT package...
by Stéphane Sudre 29 May '02

29 May '02

On Wednesday, May 29, 2002, at 06:05 PM, Dean Reece wrote: 2) I do agree with the fact that owner/group must be root/wheel for items inside /System but I do not agree that it should be the case when they are in /Library. The ownership requirement is necessary regardless of location for security reasons. A KEXT contains a binary that is loaded into the kernel and executed. If that binary can be written by non-admin users, then it can become a vehicle for all sorts of nasty attacks. For the purposes of security, a KEXT must be thought of as a setuid binary and treated as such. This is why I don't understand why rwxrwxr-x root/admin is considered incorrect: - with this setting, the binary can't be written by non-admin users. - if an user is in admin but not wheel then he can create a Startup Item which will be launched at boot time with the root privileges. So instead of trying to change a kext, would I want to do a nasty attack, I would just create a Startup script with rm -r /Users for instance. Maybe due to some HFS+ stuff (don't remember if the fact that you couldn't rm files with the Lock option set from the Finder has been fixed or not) I may not be able to delete everything but it will be nasty. In fact I just did the test. I created an user with admin permission. I then remove it from wheel using NetInfo. I logged in with this user account and created a small StartupItem whose sole purpose was to touch a file in /Library/StartupItems/. The StartupItem was launched and the file was created with -rw-r--r-- root admin permission. So I tend to believe a rm -r /Users would be nasty if sent from this script. This requires a reboot but since you need to be root or sudoed to kextload a kext, this is quite the same situation. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Problem with the privileges of the KEXT package...
by Dean Reece 29 May '02

29 May '02

On Wednesday, May 29, 2002, at 03:55 AM, Stiphane Sudre wrote: On Wednesday, May 29, 2002, at 09:17 AM, Kevin Van Vechten wrote: Moreover than making the KEXT inaccessible to the group, it probably should not be in /Library/, since that is (and should be) group writable, limiting the effectiveness of any permissions to the KEXT. A purist such as myself would contend that KEXTs belong in /System/Library/Extensions, owned by root:wheel. The KEXT system was designed to load KEXTs from anywhere as long as their ownership & permissions were acceptable. Having a StartupItem load them directly from within its own bundle is reasonable use of the mechanism. We also envisioned applications that contain KEXTs which only need to be considered while the app is running (e.g., a special network sniffer tool). On Tuesday, May 28, 2002, at 08:37 PM, Dean Reece wrote: Right; the "standard" permissions we recommend are 644 for files and 755 for dirs. The owner/group should be root/wheel. Minimally, your kext (all files & dirs) must be owned by root and may not be writable by any user other than root. Obviously, to be read by the kext loading system they need to be readable by root, but should also be readable by non-root users in order for Finder and AppleSystemProfiler to be able to present them in the GUI. Thanks for all the answers, I tested with just removing the write permission to the files and folders and it's now working. Cool. Yet I must confess I have some problems with this scheme. 1) I don't like putting 3rd party kext (mine or others) in /System/Library/Extensions: The original decision to only scan /S/L/E by default is still the current implementation. For future releases we may considered scanning other places, but no plans have been made to do so. 2) I do agree with the fact that owner/group must be root/wheel for items inside /System but I do not agree that it should be the case when they are in /Library. The ownership requirement is necessary regardless of location for security reasons. A KEXT contains a binary that is loaded into the kernel and executed. If that binary can be written by non-admin users, then it can become a vehicle for all sorts of nasty attacks. For the purposes of security, a KEXT must be thought of as a setuid binary and treated as such. * Since the owner/group of /Library is root/admin, this would be incoherent. * The kextload tool does not care at all whether the files are root/wheel or root/admin. It just works with root/admin. Right - The recommended ownership is root/wheel, but since group writability is not allowed the actual group ownership can be anything you prefer. 3) I don't see the interest to deny group write permissions to a kext associated to a StartupItem. * Denying write permissions prevent the file to be deleted from the Finder. See point above about the Apple Installer. Both the installation and removal of a KEXT requires authentication. * Denying write group permissions protects almost nothing: - Prevent the deletion of the kext: not really (see above) - Prevent files with inappropriate permissions to be launched at boot time: Startup Items can be in /Library/ and their associated scripts or binary can be rwxrwxr-x root/admin, and are launched at boot time. - If it's there to prevent the End user from deleting the file, write group permissions with root/admin is fine too. With the current permissions giving write permission to the admin group, what I'm experiencing is this: - End User can't delete the items - End User can't delete the /Library folder - End User can't change the items - Admin User can delete /Library - Admin User can delete /System - Admin User can delete the items (included from the Finder) - Admin User can change the items I'm trying to imagine a case where giving write permissions to the admin group can lead to a security issue but since this is already the case with StartupItems... We started with a very conservative set of requirements for KEXT security with the understanding that we could relax them a bit if needed. Presently, we have no plans to relax them, though if we hear of specific cases that needlessly hinder end users, we'll have a look. We won't relax them to the point that we compromise security though. Side note: is there any official Apple/Darwin document which lists the recommended file permissions for the various standard locations? Not that I'm aware of. A good rule of thumb is to duplicate the ownership & permissions of other items installed by Apple Software into the same location. Cheers, - Dean _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Problem with the privileges of the KEXT package...
by Stéphane Sudre 29 May '02

29 May '02

On Wednesday, May 29, 2002, at 09:17 AM, Kevin Van Vechten wrote: Moreover than making the KEXT inaccessible to the group, it probably should not be in /Library/, since that is (and should be) group writable, limiting the effectiveness of any permissions to the KEXT. A purist such as myself would contend that KEXTs belong in /System/Library/Extensions, owned by root:wheel. On Tuesday, May 28, 2002, at 08:37 PM, Dean Reece wrote: Right; the "standard" permissions we recommend are 644 for files and 755 for dirs. The owner/group should be root/wheel. Minimally, your kext (all files & dirs) must be owned by root and may not be writable by any user other than root. Obviously, to be read by the kext loading system they need to be readable by root, but should also be readable by non-root users in order for Finder and AppleSystemProfiler to be able to present them in the GUI. Thanks for all the answers, I tested with just removing the write permission to the files and folders and it's now working. Cool. Yet I must confess I have some problems with this scheme. 1) I don't like putting 3rd party kext (mine or others) in /System/Library/Extensions: * Since the Apple Installer which I'm using does not provide any Uninstall feature, the End User can't remove stuff in /System since he can't guess where it is and sometimes he can't even guess the name of the file or determine whether this is an Apple Extension or a 3rd party Extension. * If you install 3rd party files in /System/Library/, the user will have reasons to dig in /System/Library/Extension. First thing he will do is to remove the Graphic Drivers he does not need. Even though these drivers are not loaded at boot-time. He will also remove the iPod driver, the Apache Startup Items, etc... This will lead to a corrupted System Folder which may lead to incorrect Mac OS X updates. * If one user can change stuff in /Library/ he can change stuff in /System/Library too. Since Admin users in OS X are in staff, admin, wheel, they can become root and trash /System/Library. So /Library is not more protected than /Library to these users. The protection to common users is the same in /System and /Library (other: r-x for folders and r-- for files). * I don't see a great interest in putting StartupItems in /Library and the associated kexts in /System/Library/Extensions. To remove the whole package you would need to remove components at 2 locations when you can only remove components at one location. * I don't see the interest of being able to put StartupItems in /Library if you can't put their associated kext inside them. I thought the Mac OS X experience was to group stuff and not putting them everywhere when possible. 2) I do agree with the fact that owner/group must be root/wheel for items inside /System but I do not agree that it should be the case when they are in /Library. * Since the owner/group of /Library is root/admin, this would be incoherent. * The kextload tool does not care at all whether the files are root/wheel or root/admin. It just works with root/admin. 3) I don't see the interest to deny group write permissions to a kext associated to a StartupItem. * Denying write permissions prevent the file to be deleted from the Finder. See point above about the Apple Installer. * Denying write group permissions protects almost nothing: - Prevent the deletion of the kext: not really (see above) - Prevent files with inappropriate permissions to be launched at boot time: Startup Items can be in /Library/ and their associated scripts or binary can be rwxrwxr-x root/admin, and are launched at boot time. - If it's there to prevent the End user from deleting the file, write group permissions with root/admin is fine too. With the current permissions giving write permission to the admin group, what I'm experiencing is this: - End User can't delete the items - End User can't delete the /Library folder - End User can't change the items - Admin User can delete /Library - Admin User can delete /System - Admin User can delete the items (included from the Finder) - Admin User can change the items I'm trying to imagine a case where giving write permissions to the admin group can lead to a security issue but since this is already the case with StartupItems... Any opinion? Side note: is there any official Apple/Darwin document which lists the recommended file permissions for the various standard locations? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Problem with the privileges of the KEXT package...
by Kevin Van Vechten 29 May '02

29 May '02

On Tuesday, May 28, 2002, at 11:08 AM, Joshua Graessley wrote: Your contents should not be writable by the group. Moreover than making the KEXT inaccessible to the group, it probably should not be in /Library/, since that is (and should be) group writable, limiting the effectiveness of any permissions to the KEXT. A purist such as myself would contend that KEXTs belong in /System/Library/Extensions, owned by root:wheel. -Kevin On Tuesday, May 28, 2002, at 11:02 AM, Stiphane Sudre wrote: Stupid question: what privileges are supposed to be put on the components of a KEXT package? The next major release of OS X (and so the next major release of Darwin I suppose) thinks that the following privileges are bad : .kext folder: drwxrwxr-x 4 root admin Contents folder: drwxrwxr-x 6 root admin Info.plist file: -rw-rw-r-- 1 root admin Mac OS folder: drwxrwxr-x 3 root admin binary: -rw-rw-r-- 1 root admin At least that's what kextload -tv is saying. So what are the correct privileges supposed to be? The KEXT is in /Library/StartupItems _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0