Problem
In macOS 10.13, 3rd party kernel extensions are prevented from being loaded as long as the end user has not "trusted" them via the System Preferences > Securtiy & Privacy > General > Allow… dialog.
Before High Sierra, a launchd daemon calling kextload could reasonably expect the kernel extension to be actually loaded after the call as long as the .kext bundle was correcly located with approrpiate permissions.
Now in High Sierra, a launchd daemon would need to take into account that kextload can return a value specifying that the system policy blocked the loading (27?) and that the kext will be loaded eventually or not.
So adding asynchronism to the launchd daemon could be a good idea.
One possible solution would be for the launchd daemon to listen to kernel event posted by the kernel extension at the end of its start callback.
Unfortunately, there seems to be a chicken and egg problem:
- for the launchd daemon to receive kernel events informing it that the kernel has been loaded ,the launchd daemon needs to be able to retrieve the vendor code via a ioctl call.
- as far as I can tell, ioctl(_rawSystemSocket, SIOCGKEVVENDOR,&tVendorCode) fails if the vendor code has not been allocated at the kernel level.
- as far as I can tell, to allocate the vendor code, the kernel extension needs to be loaded and have called kev_vendor_code_find().
Question
Am I missing something or kernel events are not a solution to properly address the problems introduced by the new system policy mechanism?
Is polling (*) the only (and stupid) solution available?
* for instance by trying to register a kext control socket periodically
Side note: is there any plan to fix the forum text editor. It's a nighmare.
