site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On mercredi, novembre 30, 2005, at 12:31 AM, Terry Lambert wrote: Thanks Carl This is not always useful. For this requirement, the kext must load at system startup. My $0.02 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Nov 29, 2005, at 2:29 AM, Stephane Sudre wrote: On 28 Nov 2005, at 23:03, Carl Smith wrote: Actually after some thought, I think a better question would be, does anyone know of a carbon or generic call that I could use to tell if the ‘Network’ is up before trying to load my NKE from my >>> app? Frankly, the best solution IMHO would be to stick with your StartupItem since it avoids the need to ask for root authentication each time you want to load the kext. It's not that complex to add some polling code to check that the kext is loaded. If you need to support 10.4 and later only, a kext control socket can be the solution. As long as you can't connect to the socket, this means your kext is not loaded. There have been several questions recently regarding loading Network Extensions at startup, and starting applications as soon as network extensions are successfully loaded, etc., that are reminiscent of the tasks one might like to perform if one were writing commercial single user machine firewall software, with the intent of having the software request direction on a course of action for a given intrusion event (e.g. "should 192.168.0.35 be allowed to connect to your AFP shares exported by this machine?" .. "yes, 192.168.x.x is on my local network"). For example, if you were attempting to write the MacOS X equivalent of the Windows products "Black ICE Defender" or "Zone Alarm Pro", you would specifically have the following application requirements: (1) Your kext would need to be loaded and interfaced with the networking stack before the network was in fact enabled, so that no packets were permitted to pass through the networking interace to a potentially vulenrable program on the host system, until the defensive software was in place. To achieve this, you would have to use IOKit matching - the KEXT would need to implement an IOKit device driver, and that driver would have to always claim that it had discovered matching hardware. For this requirement, you would also need to ensure that the kext was loaded before network startup. To achieve this, you would need to claim that the device driver was a "Root" device - that is, it was required in order to mount the Root volume so that the OS was capable of booting; note that making this requirement endangers the system: a bug in this device driver could result in an unrecoverable boot failure requiring either a reinstall, or a boot from install media and an escape to a shell or a boot from an alternate partition. Your point on "Root" device is not exactly right AFAIK. "Root" device startup can be prevented. With some code, the I/O Kernel extension can know that the boot was made in Safe mode and so perform differently or return failure on loading. Concerning the point of being loaded before the network stack is enabled, there's a problem in Tiger where the callback which could be used to be loaded before the stack is enabled (so that for instance you can attach socket filters the sooner possible) is never called before the stack is enabled. At least, that's been my experience. This is a known problem AFAIK. This email sent to site_archiver@lists.apple.com