Detailed analysis of Copy_from_user and Copy_to_user based on ARM architecture (with MMU)

[Turn from: http://blog.chinaunix.net/uid-20543672-id-3195249.html] When learning about Linux kernel drivers, you will encounter Copy_from_user and Copy_to_ from the start User of these two commonly used functions. These two functions are used very frequently in the kernel and are responsible for copying data from the user space to the kernel space and copying the data from the kernel space to the user space. When I first learned about Linux kernel drivers before 4.5, I just knew how to use them and did not analyze them in depth. This time when the kernel modules were mounted, they were encountered. Decide whether to follow the function carefully. First, the prototypes of these two functions are in the Arch/arm/include/asm/uaccess.h file:

2. Static inline unsigned long __must_check copy_from_user (void *to, const void __user *from, unsigned long N)
4. {
6. if (Access_ok (Verify_read, from, N))
8. n = __copy_from_user (to, from, N);
10. else/* Security Hole-plug it */
12. memset (to, 0, N);
14. return n;
16. }
20. Static inline unsigned long __must_check copy_to_user (void __user *to, const void *from, unsigned long N)
22. {
24. if (Access_ok (Verify_write, to, N))
26. n = __copy_to_user (to, from, N);
28. return n;
30. }

These two functions from the structure of analysis, in fact, can be divided into two parts: 1, first check the user space address pointer is valid (difficulty) 2, call __copy_from_user and __copy_to_user function in this analysis, we first easy later difficult. First look at the __copy_from_user and __copy_to_user functions of the specific data copy function for the ARM architecture, there is no separate implementation of these two functions, so their code is located in the Include/asm-generic/uaccess.h

2. /*
4. * The framework with the MMU should cover these two functions
6. */
8. #ifndef __copy_from_user
10. Static inline __must_check long __copy_from_user (void *to,
12. const void __user * FROM, unsigned long n)
14. {
16. if (__builtin_constant_p (n)) {
18. Switch (n) {
20. Case 1:
22. * (U8 *) to = * (U8 __force *) from;
24. return 0;
26. Case 2:
28. * (u16 *) to = * (U16 __force *) from;
30. return 0;
32. Case 4:
34. * (U32 *) to = * (u32 __force *) from;
36. return 0;
38. #ifdef Config_64bit
40. Case 8:
42. * (U64 *) to = * (u64 __force *) from;
44. return 0;
46. #endif
48. Default
50. Break
52. }
54. }
58. memcpy (To, (const void __force *) from, n);
60. return 0;
62. }
64. #endif
68. #ifndef __copy_to_user
70. Static inline __must_check long __copy_to_user (void __user *to,
72. const void *from, unsigned long N)
74. {
76. if (__builtin_constant_p (n)) {
78. Switch (n) {
80. Case 1:
82. * (U8 __force *) to = * (U8 *) from;
84. return 0;
86. Case 2:
88. * (U16 __force *) to = * (U16 *) from;
90. return 0;
92. Case 4:
94. * (u32 __force *) to = * (U32 *) from;
96. return 0;
98. #ifdef Config_64bit
100. Case 8:
102. * (U64 __force *) to = * (U64 *) from;
104. return 0;
106. #endif
108. Default
110. Break
112. }
114. }
118. memcpy (void __force *) to, from, N);
120. return 0;
122. }
124. #endif

Click (here) to collapse or open

1. GCC's built-in function, __builtin_constant_p, is used to determine whether a value is a compile-time number, and if the parameter value is a constant, the function returns 1, otherwise returns 0.

From the two functions can be seen in fact the structure is the same, first to see if n is a constant, if it is 1, 2, 4, 8 (64bit) directly with an assignment statement copy data. If it is not a constant or n is too large, use the memcpy function. And this memcpy function is located in LIB/STRING.C:

2. #ifndef __have_arch_memcpy
4. /**
6. * Memcpy-copy One area's memory to another
8. * @dest: Where to copy to
10. * @src: Where to copy from
12. * @count: The size of the area.
14. *
16. * You should don't use this function to access IO space, use Memcpy_toio ()
18. * or Memcpy_fromio () instead.
20. */
22. void *memcpy (void *dest, const void *SRC, size_t count)
24. {
26. char *tmp = dest;
28. const char *s = SRC;
32. while (count--)
34. *tmp++ = *s++;
36. return dest;
38. }
40. Export_symbol (memcpy);
42. #endif

This function is actually a simple use of loops to copy data, very simple. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ How to copy data we already know, now let's take a look at the previous user space pointer detection function ACCESS_OK, which is actually a macro definition, located in arch/arm/ In the Include/asm/uaccess.h file:

1. /* We use 33-bit arithmetic ... * *
2. #define __RANGE_OK (addr,size) ({\
3. unsigned long flag, roksum; \
4. __chk_user_ptr (addr); \
5. __asm__ ("adds% 1,% 2,% 3; Sbcccs% 1,% 1,% 0; MOVCC%0, #0 "\
6. : "=&r" (flag), "=&r" (roksum) \
7. : "R" (addr), "Ir" (size), "0" (Current_thread_info ()->addr_limit) \
8. : "CC"); \
9. Flag })
11. ......
13. #define ACCESS_OK (Type,addr,size) (__RANGE_OK (addr,size) = = 0)
14. ......

This is more troublesome, involving the C language in the inline assembly, if you are not familiar with the friend can see "ARM GCC Embedded Assembler manual", I am not very familiar.

Now let's examine the macro __RANGE_OK:

(1) unsigned long flag, roksum;\\ define two variables

1. flag: The variable that holds the result: the non-0 represents an invalid address, and 0 means that the address can be accessed. Initially holds a non-0 value (Current_thread_info ()->addr_limit), which is the upper address value of the current process.
3. roksum: Saves the end of the address range to be accessed for comparison with the current process address space limit data

(2) __chk_user_ptr (addr); \ \ definition is an empty function

However, this function involves the __CHECKER__ macro, which is defined by the __CHECKER__ macro when it checks the kernel code through the sparse (Semantic Parser for C) tool. The tool is called when using make C=1 or c=2, which examines the kernel functions and variables that declare the related properties that sparse can inspect in code.

If __checker__ is defined, this is explained in the online material: __chk_user_ptr and __chk_io_ptr only declare functions here, there is no function body, the purpose is to compile the process sparse be able to catch the compilation error, check the parameters of the type.

If __checker__ is not defined, this is an empty function.

(3) The next compilation, I translate the following appropriately:

adds%1,%2,%3

Roksum = addr + Size This operation affects the status bit (the purpose is to influence the rounding flag C)

The following two instructions have conditional cc, which is when c=0 is executed.

If the addition instruction above is carried (c=1), the following instruction is not executed, and flag is the initial value current_thread_info ()->addr_limit (not 0 value) and returns.

If there is no carry (c=0), execute the following instruction

Sbcccs% 1,% 1,%0

Roksum = Roksum-flag, i.e. (addr + size)-(Current_thread_info ()->addr_limit), the operation affects the sign bit.

if (addr + size) >= (Current_thread_info ()->addr_limit), then c=1

if (addr + size) < (Current_thread_info ()->addr_limit), the c=0

execute the following command when C=0, otherwise skip (flag not 0).     MOVCC%0, #0flag = 0, assigning a value of 0 to flag

(4) Flag;  

Return flag value

The __RANGE_OK macro is actually equivalent to:

if (addr + size) >= (Current_thread_info ()->addr_limit), returns a value other than 0

if (addr + size) < (Current_thread_info ()->addr_limit), returns zero

The ACCESS_OK is to verify that the address range of the user space that will be manipulated is in the user address space limit of the current process. The function of this macro is very simple, it can be implemented in C, it is not necessary to use the assembly. Personal understanding: Because these two functions are used frequently, the assembly is used to achieve some of the functions to increase efficiency.

once again, it can be realized thatthe use of Copy_from_user and Copy_to_user is in the context of the process, because they want to access "user" Memory space, this "user" must be a specific process. It is known through the source code above, where Current_thread_info () is used to check if the space is accessible. If you use these two functions in a drive, you must use them in the function that implements the system call and not in the function that implements the interrupt processing. if used in an interrupt context, the code is likely to operate a process address space that is not related at all.

Second, because the manipulated page may be swapped out, the two functions may hibernate, so it is also not available in the interrupt context.

Detailed analysis of Copy_from_user and Copy_to_user based on ARM architecture (with MMU)