> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] 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


_______________________________________________
Kernelnewbies mailing list
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to