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: Terry Lambert <email@hidden>
- Date: Tue, 29 Nov 2005 15:31:27 -0800
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.
(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.
It all depends on your application.
(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").
-- Terry _______________________________________________
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