I would like to a lib that is equivalent to getpwuid() from LKM module which is in kernel space to get "passwd" structure.
Will you advice me how I can do it to get the "passwd" structure from kernel space not from user space?
Thank you.
//DAUM
It is extremely unlikely you have any valid reason to do this. You will have to elaborate.
In short, the setup can be quite complicated and e.g. involve querying databases on different machines. For /joke/ purposes one could implement that by having a userspace helper for the kernel.
Related
I am making a /proc entry for my driver. So, in the read callback function the first argument is the location into which we write the data intended for the user. I searched on how to write the data in it and i could see that everybody is using sprintf for this purpose. I am surprised to see that it works in kernel space. However this should be wrong to use a user space function in kernel space. Also i cant figure out how to write in that location without using any user space function like strcpy, sprintf, etc. I am using kernel version 3.9.10. Please suggest me how i should do this without using sprintf or any other user space function.
Most of the 'normal' user-space functions would make no sense in kernel code, so they are not available in the kernel.
However, some functions like sprintf, strcpy, or memcpy are useful in kernel code, so the kernel implements them (more or less completely) and makes them available for drivers.
See include/linux/kernel.h and string.h.
sprintf is a kernel-space function in Linux. It is totally separate from its user-space namesake and may or may not work identically to it.
Just because a function in user-space exist, it does not mean an identically named function in kernel-space cannot.
As the title has said, I'm looking for how I can read/write blocks directly to disk in linux kernel space (bypassing the file system) and directly interact with block IO layer.
After reading through some kernel codes, I realize bio is the structure I should be using to achieve such goal in block IO layer. But I don't quite understand the structures of bio and haven't figure out how exactly I can do that.
Any helps? Thank you
If you're only doing something simple, you don't really need to mess with BIO. What you can do instead is to simply open the block device (/dev/whatever) as if it was a file. The kernel will do the right thing and will give you the "thin" wrapper for read/write operations.
In regard to opening the file from the kernel space, there are few questions here, already answered, like this one:
How to read/write files within a Linux kernel module?
If you want to do anything more fancy, you will have to study the sources of the FS drivers (in the fs/ subdirectory) to hunt for examples.
In case anyone is interested in doing this with Node.js, we released a native add on yesterday with helpers for opening and working with block devices: https://github.com/ronomon/direct-io
I am trying to measure the performance of some library calls. My primary measurement tool is the rdtsc call. After doing some reading I realize that I need to disable preemption and interrupts in order to get the most accurate readings. Can someone help me figure out how to do these? I know that pthreads have a 'set affinity' mechanism. Is that enough to get the job done?
I also read somewhere that I can make calls into the kernel of the sort
preempt_disable()
raw_local_irq_save(...)
Is there any benefit to using one approach over the other? I tried the latter approach and got this error.
error: 'preempt_disable' was not declared in this scope
which can be fixed by including linux/preempt.h but the compiler still complains.
linux/preempt.h: No such file or directory
Obviously I have not done any kernel hacking and I could not find this file on my system anywhere. I am really hoping I wont have to install a new linux kernel. :)
Thanks for your input.
Pinning a pthread to a single CPU can be done using pthread_setaffinity_np
But what you want to achieve at the end is not so simple. I'll explain you why.
preempt.h is part of the Linux Kernel source. Its located here. You need to have kernel sources with you. Anyways, you need to write a kernel module to access it, you cannot use it from user space. Learn how to write a kernel module here. Same is the case with functions preempt_disable and other interrupt disabling kernel functions
Now the point is, pthreads are in user space and your preemption disabling function is in kernel space. How to interact?
Either you need to write a new system call of your own where you do your preemption and interrupt disabling and call it from user space. Or you need to resort to other Kernel-User Space Interfaces like procfs, sysfs, ioctl etc
But I am really skeptical as to how all these will help you to benchmark library functions. You may want to have a look at how performance is typically measured using rdtsc
As part of my project I need to read the kernel to get the memory address of system call table and system call address. Or in effect i need to extract the contents of the system call table and all the system calls.
Till now I use GDB for this purpose. Is there any way so that I could do it using a kernel module. I am new the kernel module programming. Looking for advice from experts here.
Let me first start by saying reading arbitrary kernel memory is tricky business! And there are many ways to do it, which vary in their degree of complexity and flexability.
1) Hard-code the address.
Search for it in your kernel version's System.map file:
# grep sys_call_table /boot/System.map-2.6.18-238.12.1.el5
c06254e0 R sys_call_table
With this, hard-code the address:
unsigned long *syscall_table = (unsigned long *)0xc06254e0;
Then, assuming you #include <linux/syscalls.h>, you can use the __NR_syscall definitions to grab the addresses of those syscalls within the code:
syscall_table[__NR_close]
This is the easiest method, but by far the least flexible. This module will only work on that exact kernel. If you insmod it into a different kernel, you're liable to get a kernel OOPs.
2) Brute-force scan for the table
Have a look at this:
http://memset.wordpress.com/2011/03/18/syscall-hijacking-dynamically-obtain-syscall-table-address-kernel-2-6-x-2/
He uses a method to brute force the kernel memory address range to find the sys_call_stable. As-is, it only works on 32bit (64bit has a different memory address range for the kernel).
This method is somewhat flexible, but may break down the road as the kernel semantics change.
3) Dynamically search System.map load time
You can read your kernel's System.map file when you load the module. I demonstrate this in the tpe-lkm module I wrote. The project is hosted on github.
Have a look at the find_symbol_address_from_file() from this file:
https://github.com/cormander/tpe-lkm/blob/master/symbols.c
Very flexible, as you can find any symbol you want, but reading files from kernel space is a big 'no no'. Don't ask me why, but people are always telling me that. You also run the risk that the System.map it looks at is invalid, and could cause a kernel OOPs. Also, the code is... messy.
4) Use kallsyms_on_each_symbol()
As of around kernel version 2.6.30, the kernel exports kallsyms_on_each_symbol(). We can thank the ksplice folks for that. With this you can't find the sys_call_table (it isn't in there for some reason), but you can find most other symbols.
Very flexible, very stable method of finding addresses of symbols, but somewhat complicated to understand ;)
I demonstrate this in my tpe-lkm project. Have a look at the find_symbol_callback() and find_symbol_address() function in this file:
https://github.com/cormander/tpe-lkm/blob/master/symbols.c
I have a piece of C code which with a chunk of memory(static array) can mimic file operations (It has APIs similar to fopen/fclose etc). So, any code that is compiled with this mimicking FileSystem can use these APIs as a FileSystem for all their needs :)
But I was wondering, if its possible somehow to register these APIs with Linux system/mouning this File system, and hence enabling any client to use this FS by using normal FileSystem calls (without any need of statically linking it with the My_FileSystem).
While searching for a solution, I came across this idea of making my_FileSystem as a Driver!!! =>
Is it possible to compile my code as a device driver (with the memory chunk in the driver) and mount this File_system # say "/mnt/MyFs", and divert FileSystem calls like USB drivers do? (If this can be done, can you please explain how its done or point me to somewhere I can read about this).
I don't want to add these as new System calls and recompile the kernel (And making life of ppl wanting to use this difficult).
This is mainly for embedded systems running Linux... But other suggestions are also welcome. :)
Thank You,
MicroKernel :)
Look at FUSE (Filesystem in Userspace), especially on examples. Its quite easy...
Take a look at tmpfs and ramfs. These already ship with Linux and do all that you're trying to do and more. I don't think either of them would be too expensive for an embedded system.
I would consider PlasticFS, but that will work reliably only if everything uses system C library (i.e. no statically linked binaries).