Interact with kernel module hashtable from user space [closed] - c

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to create a linux kernel module that allows for key value store functionality to be used by other programs in user space. I'm not sure how to go about interacting with the two.
My thought is to use hashtables and make something basic for now, like this:
struct hashtable{
char name[100];
int data;
struct hlist_node my_hash_list;
}
static int hash_table_init(void){
//TODO
return 0;
}
module_init(hash_table_init);
More specifically; with a basic module like this, how would I perform operations such as adding to the hashtable from user space? I understand file operations are one way to communicate to and from the module, but I'm not sure how that would work in this case, if applicable.

Answer 1

I think the most common paradigm used is VFS based operations on either sysfs or devfs. Using struct file_operations you can define a vtable for handling userspace operating on your virtual file. This is explained in much greater detail here.
In your specific case, a miscdevice would be the best approach with IOCTLs defined to add, get or remove entries from your hashtable. A great example of a basic miscdevice driver can be found here. Your IOCTL could take a userspace address use copy_from_user to get the necessary buffer pointed to by data in the IOCTL invocation (like the name of the key or the hash) and similary a IOCTL to get something by using copy_to_user to copy the contents of a specific key to userspace. (similar to BSD's copyin/copyout).
Netlink sockets are another way of user<->kernel communication, you can find an example here. They're slightly more complicated to use, I would not suggest them if you're just starting out with kernel development.
If you want to mess with arch/ code you could also add your own system call that would call into your driver, that requires that a certain part of your driver is always present in the kernel, at least to check if the driver is loaded and forward the call. If you're going that way you cannot compile the whole driver as a module and you should generally not try to do the split approach I just described and make sure it's only compilable as part of the kernel.
Now onto the scary part, you really are playing with fire here, in the kernel you have to be extremely vigilant in terms of boundary checks, locking, preemption awareness (ie. don't yield under a spinlock), resource management and address checks since you will crash the system or even worse introduce a security vulnerability should something go wrong.
I would not suggest trying this, unless this is just for learning how to do kernel development. Even a basic driver like the ones in the example can easily introduce critical security bugs or instability into the kernel.
If this is not just for learning then may I suggest memcached or Redis both of which are userspace and have been battle-tested and are in use by many companies as out-of-process shared hashtables, with or without network transparency (ie. Redis can work over a UNIX domain socket).