How to mmap kernel memory area to userspace ?

[Jeff Haran]

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-bounces at kernelnewbies.org] On Behalf Of lxgeek
> Sent: Tuesday, August 19, 2014 2:54 AM
> To: kernelnewbies
> Subject: How to mmap kernel memory area to userspace ?
> 
> hi all:
>        I want to mmap a kernel memory area which sk_buf->data pointer
> into userspace. I want to do this , because this way can reduce a copy
> from kernel to userspace.
>        How to fix it? Or, which book or project can help me ?
> 
> Thank you.

One approach that I had some limited success with recently as part of an investigative exercise was to mmap /dev/kmem in the context of the process you want to access the skb data in. You'll need to figure out the block of kernel virtual addresses to map based on your target architecture, but basically it needs to cover the kmem cache that the TCP/IP stack allocates skbs from. Then you need to get the virtual address of the skbs' data up to user space, somehow (for instance create a device that registers hooks with netfilter, steals and queues the skbs that get passed to it and then make the virtual addresses in the queued skbs available to be read from the device). Then it's just a matter of some pointer arithmetic to determine the corresponding address of the skb payload in the pointer you get back from the call to mmap().

I am aware of a couple of potential obstacles to contend with here depending on your kernel and architecture:

CONFIG_STRICT_DEVMEM - If this kernel config is enabled in your kernel, you won't be able to do this. It's a security thing. You'd need to turn this off to proceed down this path.
CONFIG_X86_PAT - If your target is X86_64, then this kernel config will prevent you from mmap()'ing /dev/kmem, too. It's not clear to me what the effect of turning this config off is, I'm no expert in X86_64 memory management. When I tried it, the resultant kernel booted ok and seemed to function on our X86_64 target systems, but just doing read access of the data from the mmap()'ed region did occasionally generate error messages from the kernel and eventual soft lockups.

For me, it worked well enough to complete the investigation but we didn't try to productize this.

Good luck, what you are trying to do is not easy to get right in my experience,

Jeff Haran