内核栈溢出

在Linux系统上,进程运行分为用户态与内核态,进入内核态之后使用的是内核栈,作为基本的安全机制,用户程序不能直接访问内核栈,所以尽管内核栈属于进程的地址空间,但与用户栈是分开的。Linux的内核栈大小是固定的,从2.6.32-520开始缺省大小是16KB,之前的kernel版本缺省大小是8KB。内核栈的大小可以修改,但要通过重新编译内核实现。以下文件定义了它的大小:

arch/x86/include/asm/page_64_types.h
8KB:
#define THREAD_ORDER 1
16KB:
#define THREAD_ORDER 2

由于内核栈的大小是有限的,就会有发生溢出的可能,比如调用嵌套太多、参数太多都会导致内核栈的使用超出设定的大小。内核栈溢出的结果往往是系统崩溃,因为溢出会覆盖掉本不该触碰的数据,首当其冲的就是thread_info — 它就在内核栈的底部,内核栈是从高地址往低地址生长的,一旦溢出首先就破坏了thread_info,thread_info里存放着指向进程的指针等关键数据,迟早会被访问到,那时系统崩溃就是必然的事。kstack-smash

[小知识]:把thread_info放在内核栈的底部是一个精巧的设计,因为当前进程是一个使用率极高的数据结构,在高端CPU中往往都保留了一个专门的寄存器来存放当前进程的指针,比如PowerPC、Itanium,然而x86的寄存器实在是太少了,专门分配一个寄存器实在太奢侈,所以Linux设计了thread_info,把它放在内核栈的底部,这样通过栈寄存器里的指针可以很方便地算出thread_info的地址,进而得到进程的指针。

内核栈溢出导致的系统崩溃有时会被直接报出来,比如你可能会看到:

但更多的情况是不直接报错,而是各种奇怪的panic。在分析vmcore的时候,它们的共同点是thread_info被破坏了。以下是一个实例,注意在task_struct中task字段直接指向内核栈底部也就是thread_info的位置,我们看到thread_info显然被破坏了:cpu的值大得离谱,而且指向task的指针与task_struct的实际地址不匹配:

作为一种分析故障的手段,可以监控内核栈的大小和深度,方法如下:

然后检查下列数值,可以看到迄今为止内核栈使用的峰值和对应的backtrace:

你可以写个脚本定时收集上述数据,有助于找到导致溢出的代码。下面是一个输出结果的实例: