Communicate from virtual filesystem kernel extension (VFS KEXT) to user-space

Hi community,

we have a kernel extension (kext) that is serving as a virtual filesystem (VFS).

Until now we've used a local socket for the communication between kernel-space and user-space. Unfortunately sockets are provided by sys/kpi_socket in the kernel which is deprecated from macOS 10.15 on and unsupported from Big Sur (macOS 11) on. So the KEXT will not load in Big Sur...

Questions:
(1) How to communicate between kernel-space and user-space without using kpi_sockets? Any recommendations?

(2) Until my best knowledge, KEXTs for VFS aren't deprecated so far but it's foreseeable that this will come... Are there already any news about that?

Thanks in advance for your replies.

Replies

Hi,

In our kext (for the SCSI Block Command Device), we use a subclass of the IOUserClient to communicate with our user-space app.
I'm not sure you can use the same class in your kext.

The sample code is here:
https://developer.apple.com/library/archive/samplecode/SimpleUserClient/Introduction/Intro.html

Thanks,

Hi @Akira.H,
thank you very much for your suggestion. Unfortunately it's not that easy to use IOUserClient in our kernel extension as the VFS classes are part of the BSD kernel system and written in plain C. IOUserClient is part of the IOKit which is maintained in C++.

Besides that we need a solution more or less in the vice versa way as shown in the sample code. So the flow of our VFS is as follows:
  • User-space app mounts the VFS

  • VFS KEXT in kernel-space connects by using a socket (as client) to a listener in user-land

  • VFS KEXT sends requests from kernel-space to user-space via the socket.

Thanks for any additional hints.

VFS KEXT in kernel-space connects by using a socket (as client) to a
listener in user-land

This seems kinda backwards to me. As I general rule I prefer to have higher-level code connect to lower-level code, not the other way around.

Given that, I generally use a kernel control socket for this, that is <sys/kern_control.h>. I must admit to not having done this recently but as far as I can tell these are not deprecated.

Oh, one last thing:

Until my best knowledge, KEXTs for VFS aren't deprecated so far but
it's foreseeable that this will come... Are there already any news
about that?

There isn’t a direct replacement for VFS KEXTs, but many tasks that you might previously tackle that way can be done with a FileProvider extension.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thank you very much, Quinn - The Eskimo,

that's the hint in the right direction, we will try to adapt our code to use the Kernel Control. And thank you for mentioning FileProvider to be evaluated for our future needs :-)
I'm joining this thread with a related question. Please let me know if I should just start a new thread.

We similarly have a kext that implements VFS for a networked file system. In our case, normal operation is entirely handled in the kext: VFS op calls come in, requests and responses from network servers are gotten via sys/kpi_socket.h functions, then the responses are returned to the VFS callers.

With sys/kpi_socket.h now unsupported, what are the best alternatives for efficient networking from within a kext?

I suppose that socket calls could be wrapped and passed via sys/kern_control.h to a new service we would have to provide in user space specifically to make socket calls against the standard lib. That is, from the kext, we would pass the socket call to user space to call a library that would (internally) call down to and return back from kernel space, then our service would call back to our kext in the kernel with the socket result. The logical indirection is unattractive, and for the high volume of data we handle, I'm supposing that there would be a costly lot of copying between kernel and user memory.

Is this the only alternative?

For kext-centric networking, what alternative to sys/kpi_socket.h does Apple envision and recommend?

Thanks.

For kext-centric networking, what alternative to <sys/kpi_socket.h>
does Apple envision and recommend?

I don’t think there is one )-: As far as you can tell your only option is to bounce out to user space.

I suppose that socket calls could be wrapped and passed via
<sys/kern_control.h> to a new service we would have to provide in
user space specifically to make socket calls against the standard lib.

I wouldn’t do this at the Sockets API level. Rather, I’d build a higher-level abstraction and use it for my kernel/user space communication. Most network file system protocols have a command layer and that would make a good abstraction point.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks @eskimo!

Your perspicacious reply provides a valuable hint in the direction we can take.

Given that, I generally use a kernel control socket for this, that is <sys/kern_control.h>. 

For kext-centric networking, what alternative to <sys/kpi_socket.h>
does Apple envision and recommend?
I don’t think there is one )-: As far as you can tell your only option is to bounce out to user space.

I know control event can help to communicate between user and kernel. But in my kernel code,I just used socket to connect to my network filesystem.And my kernel must connect to server proactively.So I think it is not suitable.
Also, if app connect to my server in user space then transfer the data to kernel, it will greatly affect the speed of interaction.

Are there something wrong in my code?
Please see also related question: Memory buffers deprecated?
It refers to the same project.
Apparently the legacy KEXT is still loading!? Please see related question.