IPC between kext modules

Question

I was wondering if I can implement bi-directional communication channel between 2 kext modules using sockets under the domain PF_SYSTEM. this method mostly used to communicate between driver and user-space agent..

In my particular case I've got one module based on IOKit and the other which is simple kernel module with start and stop callback functions and I'd like to pass some small messages between them..

Do you think this approach is suitable for my needs or there's other preferable way (shared memory ? mach ports ? )

EDIT, after digging a little deeper, maybe there's an option to export an API from one driver to the other by modifying the client driver plist file as follows.. is it possible ?

    <key>OSBundleLibraries</key>
    <dict>
            <key>com.driver.server_driver</key>
            <string>1</string>

This however, doesn't work because when i try to manually load the client driver after the server driver already loaded (visible from kextstat), I get the No kexts found for these libraries error.

Do you control the contents of both drivers ? so why splitting them in the first place ? but anyway, I can think of an hacky to achieve your goal by defining a global variable in one driver which also have access from the other driver .. you need to look for a way to find the start point of the driver which stores the global variable (something like `image list` in lldb) and add the symbol offset to this value (take it from `nm` or read the macho structure and parse it yourself).. hope it helps — Zohar81, Dec 10 '17 at 21:30

pmdj · Answer 1 · 2017-12-13T11:36:52.783

Using messaging techniques normally used for IPC for communicationg between kernel extensions is unusual, as it's a lot more complex than taking advantage of the fact that they're running in the same address space anyway. I covered some of the details of this latter approach in my answer to your other question which you've obviously already seen, but I'm linking to for the benefit of others in a similar situation.

To answer your question: I suspect both ends of a system socket being in the kernel is probably not very well tested, and you could run into bugs in the kernel. The in-kernel public socket KPI is also quite fiddly: getting the buffering right is tricky, so I'd only use sockets if I absolutely had to, and it clearly isn't here.

My gut instinct is that Mach messaging would work more reliably and require less code, but again I think it would be quite unusual to use it in this way.

It's hard to give useful advice on exactly what you should do, as we don't know the reasons for the separation into 2 kexts, what their relationship is, what kind of communication is required, etc. There are many possible ways on how to exchange information, but whether they are a good idea will depend on the details of the project. (This sort of question isn't really suitable to Stack Overflow's format - this is the sort of problem for which a company will bring in an expert to consult. For a private project, you might have more luck on the Software Engineering Stack Exchange Site, where this sort of question is on-topic, although I'm not sure you'll get a good/useful answer. For a private project it's probably best you keep it simple and maybe combine the 2 kexts into one?)

IPC between kext modules

1 Answers1