site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thanks Carl This is not always useful. For this requirement, the kext must load at system startup. - It all depends on your application. -- Terry _______________________________________________ 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. (2) Your application could not be started until the device driver was in place. This is the current requirement under discussion here. For this requirement, the nominal solution is the one previously suggested by Mike Smith: Attempt to open the device in a loop with a timeout between attempts, and an upper bound on the number of attempts allowed before a soft failure is reported (specifically: a report that the KEXT component is not installed or has been improperly installed). Given this type of application, it's pretty obvious that the only way for the application to fail to open the device in this way is a bug in the device or application (such as a KEXT/OS version mismatch), or an improper installation procedure. Given that network operations would have to be "disabled by default", the vendor would have to allow certain operations to succeed on the network, despite any contraindications or configuration issues (the most obvious in this case is DHCP requests to obtain a system IP address for the machine, or later network connectivity - e.g. to a LAN, cable modem, DSL modem, or router, etc. - will be unsuccessful. Obviously, this is a vendor issue, and their responsibility to deal with all the mess that entails. So, it's *not* unreasonable to ask for a KEXT to be loaded at system startup time, and it's *NOT* unreasonable to want to have an application startup item immediately load and attach to a device that you expect to be there at system startup time. And it's *IS* unreasonable to expect *every* application to attempt to load the KEXT it wants to use itself, instead of having the system do it for you. (FYI: I could just as easily been talking about a KEXT that provides for password protection of directory hierarchies using the KAUTH_SCOPE_VNODE listener, and queues requests to a user space program that acts as UI to the user to request passwords the first time a directory traversal is attempted from a given login session; there are plenty of applications for this type of thing that need the ability to "deny by default until application is present to intermediate user interaction"). This email sent to site_archiver@lists.apple.com