I have a working OSX kernel extension which I would like to be automatically loaded at boot time as early as possible. The kext is using KAUTH for monitoring access on a specific path so it seems to me there won't be anything that will request it to be loaded into the kernel. In this case, copying it in /Library/Extensions (at least since Yosemite this is the recommended path for third-party extensions) won't solve my problem.
Is there a possibility to achieve this, whether or not by modifying the code or through some auxiliary configuration?
I already read about using a launchd daemon to use kextload in order to load the extension, as specified in this question, but in my case, I want it to be loaded as early as possible.
Update:
I am using a "generic" kernel extension (linked against BSD library) and not an I/O Kit based one.
I want my extension to be loaded before launchd is started.
You don't explicitly state it in the question, but I infer from the context that you're using a "generic" kernel extension (in contrast to an I/O kit based one)? These are only loaded either because another kext depends on them, or because they are explicitly loaded via kextutil/kextload or the KextManager API.
Contrast this to I/O Kit kexts, which are loaded on-demand when one of their personality dictionaries matches a registered service in the IO registry. This is usually for driving specific devices, but various non-hardware-dependent system services use the mechanism to match the 'IOResources' nub (documentation) which turns up during early boot so any kexts listing it as a provider for a personality also get loaded on boot.
So the solution would be to modify your kext to provide an IOService which matches the IOResources nub. The service itself doesn't really need to do anything if your userspace component already uses another interface to communicate with the kext.
If you don't want to change the kext's code itself, you could possibly create a dummy kext which does this, but declares your main kext as a dependency. This latter method isn't particularly elegant, but should work if for some reason modifying the existing kext is not possible. (Although you'll likely need to modify the info.plist)
If the kext is derived from IOKit and resides in /Library/Extensions clear the cache and it will be automatically loaded at boot. You clear the cache by calling
kextcache -f -update-volume /
Related
I'm writing a macOS launch daemon (in C++). It works for the most part, except that I am noticing some random crashes via SIGABRT (in the log.)
I've asked earlier about the use of the Core Graphics framework, which it turns out was not allowed in a launch daemon. I removed it, but I still get very rare crashes.
Thus I'm wondering which of the following frameworks am I allowed to use from a launch daemon?
There's no technical restriction on specific frameworks you're allowed or not allowed to link. Merely linking a library will not cause crashes. Some APIs need to be called from specific contexts, such as much of Core Graphics only making sense if a process is part of a windowing session, as you've found out. But even there, some of the off-screen drawing APIs which don't interface with the windowing system directly ought to work from a Launch Daemon context.
If you're seeing crashes calling specific APIs, you'll need to investigate those one by one. If you're seeing "random" crashes, I suspect you have a bug (memory overwrite? multithreading error?) in your code. Note that Apple's toolchain provides a bunch of different diagnostic options which you can use even when not running in the debugger, such as ASan, UBSan, and Thread Sanitizer. These may help you track down issues.
As you've specifically tagged this question with the IOKit tag and it's shown in your screenshot, I'll add that using IOKit from a launch daemon is very common. It's even possible to use IOKit matching events as a launch trigger for the daemon using XPC events/xpc_set_event_stream_handler - this way, your daemon can be started on-demand when a specific (type of) device is connected, for example. (As opposed to starting up at every system boot and consuming system resources even if it's not needed or doing anything.)
We use a publicly available kernel extension (http://tuntaposx.sourceforge.net) in our application to add tun/tap network functionality to macOS.
It appears that other applications also use the very same kernel extension, but unfortunately they modified the kext's bundle identifier, which prevents us from checking by the bundle identifier whether the same kernel extension is already loaded when our application tries to load its own copy of the kext.
Is there an alternative way of testing whether a kernel extension with the same functionality is already loaded? Maybe by calling some functions of the kext?
I'd like save a kext setting between OS restarts. As I need the settings after kext been loaded immediately, I can not wait for managing daemon start up. Is it a way for reading/writing kext plist file from kext or some other ways to do that?
Basically, no - you're supposed to store settings in userspace and use a launchd service to set them in the kext. Until your kext receives the settings, it should just use some sane defaults.
One way to truly include settings on kext startup is to add custom attributes to the IOKitPersonality in your kext's info.plist. Obviously, this means that changing settings requires changing the kext itself, but I have heard reports of people actually doing this on Apple's public darwin mailing lists (although Apple employees pitched in to criticise it). Note that the kext cache will not like this: If your userspace program changes settings in the info.plist, it will probably need to increase the bundle version number in order for the kext cache to pick up the change, otherwise the cached/prelinked kext won't see the change. You need to do this within the constraints of the rules for kext bundle versions or it won't be detected as a version increase, or worse, the kext cache will reject the kext outright. Also, don't forget to touch /System/Library/Extensions/ after updating kexts.
Update: modifying a kext's info.plist will no longer work in 10.9 and 10.10 due to the kext signing requirement.
In the specific case where your kext is a storage filter scheme, you can store your settings in a special "super block" of the provider partition. AppleRAID (which is open source) does this, for example. This isn't practical for any other kind of kext, though.
I'm writing a driver for Windows NT that provides Ring-0 access for userspace application. I want to make a utility with exclusive rights to execute any user's commands that would be protected from any external harmful influence.
Surfing the Internet I found that it is necessary to hook some native kernel functions, such as NtOpenProcess, NtTerminateProcess, NtDublicateObject, etc. I've made a working driver which protects an application but then I realized that it would be better to prevent it also from external attempts of removing the driver or forbidding its loading during OS starting like firewall. I divided the task into two parts: to prevent physical removing of the driver from \system32\drivers\ and to prevent changing/removing registry key responsible for loading the driver (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services).
The matter is that I do not understand how to hook the access to the registry key from kernel space and even not sure that it is possible: all functions from ntdll that work with registry are in the userspace, unavailable from kernelspace. Also all API hooks that I can set from userspace would be in specific proccess's memory context. So we need to inject Dll into every proccess be it current or new.
Is there a method to hook all NT-calls in one place without injecting Dll into every proccess?
You do this in wrong way. Registry calls is also nt syscalls and reside in SSDT (as another Zw* syscalls). But hooking SSDT is bad practice. Major drawbacks - its dont working on x64 systems because of PathGuard. Right way is use documented specific filtering mechanisms of OS. For registry calls it is Configuration Manager callbacks. There are some caveats for windows xp version of this callbacks (some facilities are unimplemented or bogus) but xp is dead now =). It`s very simple to use it. You can start (and end =) ) from this guide http://msdn.microsoft.com/en-us/library/windows/hardware/ff545879(v=vs.85).aspx
I am writing a kernel extention for Mac os, and i need to delete a tmp file created by
vnode_open(),but i can not find out how to delete a file and list all files in a dir.
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/KernelIOKitFramework/vnode_h/index.html
Thanks!
It is better to create user-space daemon and to communicate with it using mach RPC.
The method of deletion of file in kext (that i'm aware of) depends on the version of kernel because it requires lookup of the offset of v_op (vnode operations vector. It is not visible from kernel extensions) within vnode structure. The vnode structure may change from kernel to kernel. And even if one finds vnop_remove_desc and vnop_rmdir_desc i think using it may be dangerous due to possible changes of the logic of using these callbacks.