Board logo

标题: 利用异常表处理 Linux 内核态缺页异常（2） [打印本页]
作者: look_w    时间: 2018-5-7 18:54     标题: 利用异常表处理 Linux 内核态缺页异常（2）

GCC的扩展功能由于本文中会用到GCC的扩展功能，即汇编器as中提供的.section伪操作，在文章开始之前我再作一个简要的介绍。此伪操作对于不同的可执行文件格式有不同的解释，我也不一一列举，仅对我们所感兴趣的Linux中常用的ELF格式的用法加以描述，其指令格式如下：
1
.section NAME[, "FLAGS"]




大家所熟知的C程序一般由以下的几个部分组成：代码段（text section）、初始化数据段(data section)、非初始化数据段(bss section)、栈(heap)以及堆(stack)，具体的地址空间布局可以参考《UNIX环境高级编程》一书。
在Linux内核中，通过使用.section的伪操作，可以把随后的代码汇编到一个由NAME指定的段中。而FLAGS字段则说明了该段的属性，它可以用下面介绍的单个字符来表示，也可以是多个字符的组合。
举个例子来说明，读者在后面会看到的：.section .fixup, "ax"
这样的一条指令定义了一个名为.fixup的段，随后的指令会被加入到这个段中，该段的属性是可重定位并可执行。
内核缺页异常处理运行在核心态的进程经常需要访问用户地址空间的内容，但是谁都无法保证内核所得到的这些从用户空间传入的地址信息是"合法"的。为了保护内核不受错误信息的攻击，需要验证这些从用户空间传入的地址信息的正确性。
在老版本的Linux中，这个工作是通过函数verify_area来完成的：
1
extern inline int verify_area(int type, const void * addr, unsigned long size)




该函数验证了是否可以以type中说明的访问类型（read or write）访问从地址addr开始、大小为size的一块虚拟存储区域。为了做到这一点，verify_read首先需要找到包含地址addr的虚拟存储区域（vma）。一般的情况下（正确运行的程序）这个测试都会成功返回，在少数情况下才会出现失败的情况。也就是说，大部分的情况下内核在一些无用的验证操作上花费了不算短的时间，这从操作系统运行效率的角度来说是不可接受的。
为了解决这个问题，现在的Linux设计中将验证的工作交给虚存中的硬件设备来完成。当系统启动分页机制以后，如果一条指令的虚拟地址所对应的页框（page frame）不在内存中或者访问的类型有错误，就会发生缺页异常。处理器把引起缺页异常的虚拟地址装到寄存器CR2中，并提供一个出错码，指示引起缺页异常的存储器访问的类型，随后调用Linux的缺页异常处理函数进行处理。
Linux中进行缺页异常处理的函数如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
asmlinkage void do_page_fault(struct pt_regs *regs, unsigned long error_code)
{
……………………
    __asm__("movl %%cr2,%0":"=r" (address));
    ……………………
    vma = find_vma(mm, address);
    if (!vma)
        goto bad_area;
    if (vma->vm_start <= address)
        goto good_area;
    if (!(vma->vm_flags & VM_GROWSDOWN))
        goto bad_area;
    if (error_code & 4) {
        if (address + 32 < regs->esp)
            goto bad_area;
    ……………………
bad_area:
    ……………………
no_context:
    /* Are we prepared to handle this kernel fault?  */
    if ((fixup = search_exception_table(regs->eip)) != 0) {
        regs->eip = fixup;
        return;
    }
    ………………………
}




首先让我们来看看传给这个函数调用的两个参数：它们都是通过entry.S在堆栈中建立的（arch/i386/kernel/entry.S），参数regs指向保存在堆栈中的寄存器，error_code中存放着异常的出错码，具体的堆栈布局参见图一（堆栈的生成过程请参考《Linux内核源代码情景分析》一书）
该函数首先从CPU的控制寄存器CR2中获取出现缺页异常的虚拟地址。由于缺页异常处理程序需要处理的缺页异常类型很多，分支也很复杂。基于本文的主旨，我们只关心以下的几种内核缺页异常处理的情况：
1．        程序要访问的内核地址空间的内容不在内存中，先跳转到标号vmalloc_fault，如果当前访问的内容所对应的页目录项不在内存中，再跳转到标号no_context；
2．        缺页异常发生在中断或者内核线程中，跳转到标号no_context；
3．        程序在核心态运行时访问用户空间的数据，被访问的数据不在内存中
从上面的这几种情况来看，我们关注的焦点最后集中到标号no_context处，即对函数search_exception_table的调用。这个函数的作用就是通过发生缺页异常的指令(regs->eip)在异常表（exception table）中寻找下一条可以继续运行的指令(fixup)。这里提到的异常表包含一些地址对，地址对中的前一个地址表示出现异常的指令的地址，后一个表示当前一个指令出现错误时，程序可以继续得以执行的修复地址。
如果这个查找操作成功的话，缺页异常处理程序将堆栈中的返回地址（regs->eip）修改成修复地址并返回，随后，发生异常的进程将按照fixup中安排好的指令继续执行下去。当然，如果无法找到与之匹配的修复地址，系统只有打印出出错信息并停止运作。
那么，这个所谓的修复地址又是如何生成的呢？是系统自动生成的吗？答案当然是否定的，这些修复指令都是编程人员通过as提供的扩展功能写进内核源码中的。下面我们就来分析一下其实现机制。



欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0