I know that copy_to_user
/copy_from_user
, get_user
/put_user
functions are for this purpose.
My question is that, given
The pointer alone is not enough! You need to know which process that pointer "belongs" to.
When the process gets preempted, the pointer points into the address space of another process. The address may not be mapped any more, yadda yadda,
If that process will be the current process when you access the data, then you should use the copy_to_user/copy_from_user functions.
If the process may be scheduled out, you can try to mlock() the page in RAM and find out which is the physical ram address of the page. Whenever you want to access it, you map that physical page into a kernel virtual address.
NOTE:
Different user space application has different page table.
Below is a sample code to translate user space virtual address's into physical address. It works at x86 platform.
taskpid = find_get_pid(curpid);
task = pid_task(taskpid, PIDTYPE_PID );
mm = get_task_mm(task);
down_read(&mm->mmap_sem);
start_vaddr = vaddr;
end_vaddr = 0xC0000000;
while( start_vaddr < end_vaddr){
u32 end;
end = (( start_vaddr + PMD_SIZE) & PMD_MASK);
if( end < start_vaddr || end > end_vaddr)
end = end_vaddr;
ret = walk_pgd(start_vaddr, end, mm);
if(ret != 0){
printk("ret: %08x \n", ret);
break;
}
start_vaddr = end;
}
up_read(&mm->mmap_sem);
paddr = ret;
kaddr = __va(paddr);
mmput(mm);
You'll need to follow
an address to get a corresponding page
struct (see follow_page for the example). Next, getting the page
struct you'll need to map it to kernel's address space via kmap
or kmap_atomic
.
You may find this useful.
Let us repeat that the buff argument to the read and write methods is a user-space pointer. Therefore, it cannot be directly dereferenced by kernel code. There are a few reasons for this restriction:
Depending on which architecture your driver is running on, and how the kernel was configured, the user-space pointer may not be valid while running in kernel mode at all. There may be no mapping for that address, or it could point to some other, random data.
Even if the pointer does mean the same thing in kernel space, user-space memory is paged, and the memory in question might not be resident in RAM when the system call is made. Attempting to reference the user-space memory directly could generate a page fault, which is something that kernel code is not allowed to do. The result would be an "oops," which would result in the death of the process that made the system call.
The pointer in question has been supplied by a user program, which could be buggy or malicious. If your driver ever blindly dereferences a user-supplied pointer, it provides an open doorway allowing a user-space program to access or overwrite memory anywhere in the system. If you do not wish to be responsible for compromising the security of your users' systems, you cannot ever dereference a user-space pointer directly.
Source: http://www.makelinux.net/ldd3/chp-3-sect-7
That said, I am myself curious to know what happens if the user-space address is indeed valid, and none of the above conditions apply...