Linux Kernel Architecture

Chapter 4: Virtual Process Memory

Copying is performed by various central functions, such ascopy_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 unau-

thorized memory access operations. This ‘‘exception table‘‘ is created when the kernel image is linked

and is located between__start_exception_tableand__end_exception_tablein the binary file. Each

entry corresponds to an instance ofstruct exception_table, which, although architecture-dependent,

is almost always structured as follows:

<include/asm-x86/uaccess_32.h>

struct exception_table_entry

{

unsigned long insn, fixup;

};

insnspecifies the position in virtual address space at which the kernel expects the fault;fixupis the code

address at which execution resumes when the fault occurs.

fixup_exceptionis used to search the exception tables and is defined as follows on IA-32 systems:

arch/x86/mm/extable_32.c

int fixup_exception(struct pt_regs *regs)

{

const struct exception_table_entry *fixup;

fixup = search_exception_tables(regs->eip);

if (fixup) {

regs->eip = fixup->fixup;

return 1;

}

return 0;

}

regs->eippoints to theEIPregister that, on IA-32 processors, contains the address of the code segment

where the fault was triggered.search_exception_tablesscans the exception table for a suitable entry.^21

(^21) To be more accurate, several tables are scanned — the main kernel table and the tables registered by modules loaded dynamically
at kernel run time. As the mechanisms used are practically the same, it’s not worth describing their minor differences.