Chapter 4: Virtual Process Memory
When a fixup routine is found, the instruction pointer is set to the corresponding memory location. The
kernel executes the routine found afterfixup_exceptionreturns withreturn.
What happens if there is no fixup routine? This indicates a genuine kernel fault that is handled by the
code indo_page_fault, which follows the (unsuccessful) call ofsearch_exception_tableand results in
a kernel oops. It looks like this on IA-32 processors:
arch/x86/mm/fault_32.c
fastcall void __kprobes do_page_fault(struct pt_regs *regs,
unsigned long error_code)
{
...
no_context:
/* Are we prepared to handle this kernel fault? */
if (fixup_exception(regs))
return;
...
/*
* Oops. The kernel tried to access some bad page. We’ll have to
* terminate things with extreme prejudice.
*/
...
if (address < PAGE_SIZE)
printk(KERN_ALERT "BUG: unable to handle kernel NULL "
"pointer dereference");
else
printk(KERN_ALERT "BUG: unable to handle kernel paging"
" request");
printk(" at virtual address %08lx\n",address);
printk(KERN_ALERT "printing eip: %08lx ", regs->eip);page = read_cr3();
page = ((__typeof__(page) *) __va(page))[address >> PGDIR_SHIFT];
printk("*pde = %08lx ", page);
...
tsk->thread.cr2 = address;
tsk->thread.trap_no = 14;
tsk->thread.error_code = error_code;
die("Oops", regs, error_code);
do_exit(SIGKILL);
...If a virtual address between 0 andPAGE_SIZE - 1is accessed, the kernel reports an invalidNULLpointer
de-reference. Otherwise, the user is informed that a paging request could not be satisfied in kernel
memory — this is a kernel bug in both cases. Additional information is also output to help debug the
fault and to supply hardware-specific data;dieprints the contents of the current registers (among other
things).
Thereafter, the current process is forced to terminate withSIGKILLto save whatever can be saved (in
many cases, the system is rendered unusable by a fault of this kind).