Re: How to tell when all kexts are loaded
Re: How to tell when all kexts are loaded
- Subject: Re: How to tell when all kexts are loaded
- From: Stephane Sudre <email@hidden>
- Date: Wed, 30 Nov 2005 01:14:29 +0100
On mercredi, novembre 30, 2005, at 12:31 AM, Terry Lambert wrote:
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?
Thanks
Carl
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.
This is not always useful.
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.
For this requirement, the kext must load at system startup.
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.
My $0.02
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden