system call hooking 系统调用增加或劫持

1. 引言：这篇文章提供了一种增加自定义系统调用或劫持原有的系统调用的实现方法，只针对 linux 系统。主要思路是获取系统调用表 sys_call_table 地址，然后用新函数地址覆盖系统调用表某个元素的值，最终代码可以以modules的模式使用，也可以直接编译进内核使用。

2. 获取系统调用表基地址的方法: cat System.map | grep "sys_call_table"

3. 获取了系统调用表基地址后，如果直接修改这个表，会报错unable to handle kernel paging request at XX，这里引出本文主要要说清楚的一个问题：系统调用表的保护机制，或者更广泛而言，内核页表的保护机制。x86体系架构的页级保护参考 页级保护措施 ，概括而言，一个页面的保护，是由3个地方决定的：pte的U/S域、pte的R/W域、RC0寄存器的WP位； U/S 域指定该页面是属于user访问权限(ring3)还是supervisor(ring0,1,2)；R/W域指定页面是read-only还是read-write; RC0.WP 主要是限制supervisor状态的CPU写R/W=read-only 的页面：

 

1、read-only类型 page

★ PDE/PTE 的 W/R标志被清 0，此时属于 read-only类型 page

★ processor 在 user模式下，只能 read

★ processor 在 supervisor模式下，且 CR0.WP为 0时，可以 read-write

2、read-write类型 page

★ PDE/PTE 的 W/R标志被置 1，此时属于 read-write类型 page

★ processor 在 user模式下，可以对 user模式的 page进行 read-write

★ processor 在 supervisor模式下，可以对supervisor/user模式的 page进行 read-write

U/Sbit的设置好理解：由于我们不想用户空间的代码随意访问(读或写)内核空间的代码或数据，所以内核空间的东西所在页面的属性都是 U/S=supervisor，这样CPU在用户态时将无法访问（如果访问就是段错误）。R/Wbit的设置也好理解，对于一个page,有很多场景要求其是 read-only的；上面比较难理解的是RC0.WP 的设置。其实，该bit真正的作用是实现内核copy-on-write机制，参考what's the purpose of x86 cr0 wp bit? 

对于本文的目的来说，系统调用表的属性，U/S必须等于 supervisor ，R/W默认是 read-only, RC0.WP 默认是1，即处于supervisor的CPU无法写 Read-only的页面，这样就导致了我们获取了sys_call_table的地址后，如果直接对其中某个地址赋值，会导致kernel panic。 解决这个问题主要是两种方式： 要不就是在赋值之前，先修改RC0.WP为0；要不就是在赋值之前，修改页面属性为 read-write. 

4 下面是代码

char * hack_mkdir(const char * path)(//这里我们增加的系统调用
{
    printk(KERN_INFO "this is in hack_mkdir\n");
}

//// for 64bit
static u64 clear_cr0(void) //将 cr0.mp 置0，同时要保存原来的 cr0 的值
{
        u64 cr0 = 0;
        u64 ret;

        asm volatile ("movq %%cr0, %0"
                        : "=a"(cr0)
                     );
        ret = cr0;

        //clear the 20 bit of CR0, a.k.a WP bit
        cr0 &= ~0x10000LL;

        asm volatile ("movq %0, %%cr0"
                        :
                        : "a"(cr0)
                     );
        return ret;
}

static void setback_cr0( u64 val ) //将保存的cr0值赋回去
{
        asm volatile ("movq %0, %%cr0"
                        :
                        : "a"(val)
                     );

}
*/
// for xen system
static void set_addr_rw(void** addr) {//将页面R/W属性改为 read-write

    unsigned int level;
    pte_t *pte = lookup_address((unsigned long)addr, &level);

    if (pte->pte &~ _PAGE_RW) pte->pte |= _PAGE_RW;

}

static void set_addr_ro(void** addr) {//将页面R/W属性改为 read-only

    unsigned int level;
    pte_t *pte = lookup_address((unsigned long)addr, &level);

    pte->pte = pte->pte &~_PAGE_RW;

}

static int __init begin(void)
{
        orig_mkdir = call_table[300]; // 这里我们增加第 300 号系统调用，并将原有的地址保存
        printk(KERN_INFO "call_table[__NR_hello] = %p\n", call_table[__NR_hello]);
        //u64 cr0;
        //cr0 = clear_cr0();
        set_addr_rw(call_table);
        call_table[__NR_hello] = hack_mkdir; //?..
        //setback_cr0(cr0);
        set_addr_ro(call_table);
        printk(KERN_INFO "call_table[__NR_hello] = %p\n", call_table[__NR_hello]);

        return 0;
}

static void __exit end(void)
{
        //u64 cr0;
        //cr0 = clear_cr0();
        set_addr_rw(call_table);
        call_table[__NR_hello] = orig_mkdir;//setback_cr0(cr0);  
        set_addr_ro(call_table);
}

module_init(begin);
module_exit(end);

上面两种解决方案有什么区别呢？在我们的实验当中，系统是跑在xen hypervisor层之上的，即整个kernel的内存都是被xen虚拟化之后的内存，而xen hypervisor对 CR0 寄存器的虚拟页面有做控制（注意，这时候 cr0 不再是物理的寄存器，而是一个页面），导致如果调用clear_cr0 函数，虚拟机会panic。 这时候采用 set_addr_rw 的方案就可以。这里提到了xen虚拟机里设置cr0寄存器发生的问题