How does copy_from_user from the Linux kernel work internally?

30,177

Solution 1

The implementation of copy_from_user() is highly dependent on the architecture.

On x86 and x86-64, it simply does a direct read from the userspace address and write to the kernelspace address, while temporarily disabling SMAP (Supervisor Mode Access Prevention) if it is configured. The tricky part of it is that the copy_from_user() code is placed into a special region so that the page fault handler can recognise when a fault occurs within it. A memory protection fault that occurs in copy_from_user() doesn't kill the process like it would if it is triggered by any other process-context code, or panic the kernel like it would if it occured in interrupt context - it simply resumes execution in a code path which returns -EFAULT to the caller.

Solution 2

regarding "how bout copy_to_user since the kernel is passing on the kernel space address,how can a user space process access it"

A user space process can attempt to access any address. However, if the address is not mapped in that process user space (i.e. in the page tables of that process) or if there is a problem with the access like a write attempt to a read-only location, then a page fault is generated. Note that at least on the x86, every process has all the kernel space mapped in the lowest 1 gigabyte of that process's virtual address space, while the 3 upper gigabytes of the 4GB total address space (I'm using here the 32-bit classic case) are used for the process text (i.e. code) and data. A copy to or from user space is executed by the kernel code that is executing on behalf of the process and actually it's the memory mapping (i.e. page tables) of that process that are in-use during the copy. This takes place while execution is in kernel mode - i.e. privileged/supervisor mode in x86 language. Assuming the user-space code has passed a legitimate target location (i.e. an address properly mapped in that process address space) to have data copied to, copy_to_user, run from kernel context would be able to normally write to that address/region w/out problems and after the control returns to the user, user space also can read from this location setup by the process itself to start with. More interesting details can be found in chapters 9 and 10 of Understanding the Linux Kernel, 3rd Edition, By Daniel P. Bovet, Marco Cesati. In particular, access_ok() is a necessary but not sufficient validity check. The user can still pass addresses not belong to the process address space. In this case, a Page Fault exception will occur while the kernel code is executing the copy. The most interesting part is how the kernel page fault handler determines that the page fault in such case is not due to a bug in the kernel code but rather a bad address from the user (especially if the kernel code in question is from a kernel module loaded).

Solution 3

The best answer has something wrong, copy_(from|to)_user can't be used in interrupt context, they may sleep, copy_(from|to)_user function can only be used in process context, the process's page table include all the information that kernel need to access it, so kernel can direct access the user space address if we can make sure the page addressed is in memory, use copy_(from|to)_user function, because they can check it for us and if the user space addressed page is not resident, it will fix it for us directly.

Share:
30,177

Related videos on Youtube

Santi1986
Author by

Santi1986

Updated on May 21, 2020

Comments

  • Santi1986
    Santi1986 about 4 years

    How exactly does the copy_from_user() function work internally? Does it use any buffers or is there any memory mapping done, considering the fact that kernel does have the privilege to access the user memory space?

  • Santi1986
    Santi1986 over 12 years
    Thank You,i was sure bout direct access by the kernel,so basically i guess it does a prior check on the pointer/address that is passed onto it so as to check if some invalid address is not passed onto the function i mean to say address belonging to some other user space process...anyway i did not know bout the memory protection thing that you have mentioned....So my DOubt is wht bout in the case of copy_to_user...since the user space is passed an address within the kernel space VM....how does the user space acccess it..or is it that the kernel maps that address to some user space address
  • Santi1986
    Santi1986 over 12 years
    ok my doubt with you answer is that its fine for copy_from_user..how bout copy_to_user since the kernel is passing on the kernel space address,how can a user space process access it..does the kernel do a prior mappin into the user space VM so that the user can access it from there
  • caf
    caf over 12 years
    @Santi1986: copy_to_user() works in exactly the same way, except that the source and destination addresses are swapped - it reads from kernel addresses and writes to userspace addresses. The only check that is done in both is that the userspace address really is below the kernel/user split; there is no need to check for addresses belonging to other user processes, because copy_*_user() are called only in process context, which means that all addresses are either kernel addresses or belong to the current process.
  • Santi1986
    Santi1986 over 12 years
    Thank you for your time i just browsed though the code and found out this kernel checks the validity of the pointers through access_ok),basically function copy__user is called which internally uses this function __copy__user_inatomic which finally calls __copy*_user_ll, which does the actuall copying and also the PAGES ARE PINNED PRIOR COPYING....if the entire data is not copied its padded with zero(by the len passed to the call)