Kernel Page Faults

When kernel address space is accessed, page faults can be triggered by various conditions as described below.

□ A programming error in the kernel has caused an incorrect address to be accessed — this is a genuine bug. Of course, this should never happen in stable versions20 but does occur occasionally in developer versions.

□ The kernel accesses an invalid address passed as a system call parameter from userspace.

□ The page fault was triggered by access to an area allocated using vmalloc.

The first two conditions are genuine errors against which the kernel must guard by performing additional checks. The vmalloc situation is a legitimate reason for a page fault that must be corrected. Modifications in the vmalloc address space are not transmitted to the page tables of a process until a corresponding page fault has occurred; the appropriate access information must be copied from the master page table. Although this is not a difficult operation, it is strongly architecture-dependent, so I won't discuss it here.

The exception fixup mechanism is a last resort when handling page faults not due to accessing vmalloc area. At some points, the kernel makes preparations for intercepting incorrect accesses that are made for a legitimate reason — for example, when copying address data from userspace addresses passed as system call parameters.

20In fact, errors of this kind very rarely occur because — as you might have already noted — Linux is an extremely stable system ...

Copying is performed by various central functions, such as copy_from_user, which is discussed in the next section. At present, it is sufficient to know that access to the incorrect address may occur at only a few places in the kernel.

When data are copied to or from userspace, page faults may occur if access is made to an address in virtual address space that is not associated with a physical page. We are already familiar with this situation in user mode. When an application accesses a virtual address, the kernel automatically and transparently returns a physical page using the demand paging mechanism discussed above. If access takes place in kernel mode, the fault must likewise be corrected, albeit using slightly different means.

Each time a page fault occurs, the cause of the fault and the address in the code currently executing are output. This enables the kernel to compile a list of all risky chunks of code that may carry out unauthorized memory access operations. This ''exception table'' is created when the kernel image is linked and is located between_start_exception_table and_end_exception_table in the binary file. Each entry corresponds to an instance of struct exception_table, which, although architecture-dependent, is almost always structured as follows:

Continue reading here: Info

Was this article helpful?

0 0