Lines Matching refs:the
6 To protect itself the kernel has to verify this address.
8 In older versions of Linux this was done with the
12 This function verified that the memory area starting at address
13 'addr' and of size 'size' was accessible for the operation specified
14 in type (read or write). To do this, verify_read had to look up the
15 virtual memory area (vma) that contained the address addr. In the
21 To overcome this situation, Linus decided to let the virtual memory
26 Whenever the kernel tries to access an address that is currently not
27 accessible, the CPU generates a page fault exception and calls the
32 in arch/x86/mm/fault.c. The parameters on the stack are set up by
33 the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter
34 regs is a pointer to the saved registers on the stack, error_code
35 contains a reason code for the exception.
37 do_page_fault first obtains the unaccessible address from the CPU
38 control register CR2. If the address is within the virtual address
39 space of the process, the fault probably occurred, because the page
41 we are interested in the other case: the address is not valid, there
42 is no vma that contains this address. In this case, the kernel jumps
43 to the bad_area label.
45 There it uses the address of the instruction that caused the exception
46 (i.e. regs->eip) to find an address where the execution can continue
47 (fixup). If this search is successful, the fault handler modifies the
49 continue at the address in fixup.
53 Since we jump to the contents of fixup, fixup obviously points
54 to executable code. This code is hidden inside the user access macros.
55 I have picked the get_user macro defined in arch/x86/include/asm/uaccess.h
57 the code generated by the preprocessor and the compiler. I selected
58 the get_user call in drivers/char/sysrq.c for a detailed examination.
138 > 1: movb (%ebx),%dl /* this is the actual user access */
154 to the unified address space we can just access the address in user
155 memory. But what does the .section stuff do?????
157 To understand this we have to look at the final kernel:
182 There are obviously 2 non standard ELF sections in the generated object
183 file. But first we want to find out what happened to our code in the
200 The instructions bracketed in the .section directives are no longer
201 in the normal execution path. They are located in a different section
202 of the executable file:
222 this is the interesting part!
230 told the assembler to move the following code to the specified
231 sections in the ELF object file. So the instructions
235 ended up in the .fixup section of the object file and the addresses
237 ended up in the __ex_table section of the object file. 1b and 3b
239 backward) is the address of the instruction that might fault, i.e.
240 in our case the address of the label 1 is c017e7a5:
241 the original assembly code: > 1: movb (%ebx),%dl
244 The local label 3 (backwards again) is the address of the code to handle
245 the fault, in our case the actual value is c0199ff5:
246 the original assembly code: > 3: movl $-14,%eax
254 becomes the value pair
258 c017e7a5,c0199ff5 in the exception table of the kernel.
268 5.) search_exception_table looks up the address c017e7a5 in the
269 exception table (i.e. the contents of the ELF section __ex_table)
270 and returns the address of the associated fault handle code c0199ff5.
271 6.) do_page_fault modifies its own return address to point to the fault
273 7.) execution continues in the fault handling code.
275 8b) DL becomes zero (the value we "read" from user space)
276 8c) execution continues at local label 2 (address of the
277 instruction immediately after the faulting user access).
279 The steps 8a to 8c in a certain way emulate the faulting instruction.
282 we set EAX to -EFAULT in the exception handler code. Well, the
283 get_user macro actually returns a value: 0, if the user access was
285 return value, however the inline assembly code in get_user tries to
289 Due to the way that the exception table is built and needs to be ordered,
290 only use exceptions for code in the .text section. Any other section
291 will cause the exception table to not be sorted correctly, and the