9 12 月, 2012 – Nothing Is Secret

上周在XP系统上测试一个驱动的时候，发现驱动加载不上，“net start”命令只是给出一个无意义的错误代码，驱动的DriverEntry()入口程序还没有得到机会运行。

初步怀疑是引入函数的问题，用WDK工具Depends.exe查看了一下驱动文件，果然是由于_chkstk函数无法解析所导致。

_chkstk是个微软C编译器的辅助库函数，MSDN上对其介绍十分简略：

_chkstk Routine is a helper routine for the C compiler. For x86 compilers, _chkstk Routine is called when the local variables exceed 4096 bytes; for x64 compilers it is 8K.

当编译器察觉到局部变量太大超过限值时（X86系统限值是4K，X64t系统上是8K）, 编译器会自动插入_chkstk这个函数以保证栈空间所使用页面在内存中。

问题是发现了，但要查出来究竟在哪个函数中还是要费些心思的。从用户层移植过来不少代码，基本锁定问题出在其中，但如果一个函数一个函数寻找实在是个不讨巧的笨办法，也不符合程序人的一贯风格，便用IDA反编译驱动sys文件，于汇编代码中搜索_chkstk字串，直接锁定出了问题函数。此函数所使用的一个结构体中定义了超大数组，对栈的超常使用在内核中是相当危险的。

解决办法很简单，直接将此结构的定义放在一个从内存分配的结构中即可。问题虽已解决，但对于DDK中有关_chkstk的描述，及其相关的疑问一直让我觉得困扰，比如，为什么X86上是4K，而AMD64架构上可以是8K。

这两天终于有了时间，可以彻底地了结这个疑问了。

要想解决这个问题，还要先从用户栈的分配开始。以ReactOS代码为例，当线程创建时，CreateThread()会调用BasepCreateStack()来创建用户栈，具体可以参见ReactOS源码：
~/ReactOS/lib/kernel32/misc/utils.c。

BasepCreateStack()函数主要做三件事：

1，分配栈空间所需的虚拟内存，大小为Stack Reserve Size
2，根据Stack Commit Size锁定内存页面，如果Stack Commit Size小于Stack Reserve Size的话，需要增加一个Page，这个额外申请的Page用作Guard Page之用。
3，将栈底部的Page设定为Guard Page。

当用户栈被用尽时，会访问到栈底部的Guard Page。而对Guard Page的任何访问都会导致Page Fault的发生。Page Fault处理函数MmAccessFault()可以分析出此次Page Fault是由Guard Page导致，便会默认由用户栈处理程序MiCheckForUserStackOverflow()来处理。如果用户栈并没有溢出的话，即Stack Commit Size小于Stack Reserve Size的情况，MiCheckForUserStackOverflow()会自动向下扩展栈空间，扩展大小为GUARD_PAGE_SIZE。 GUARD_PAGE_SIZE针对不同的CPU架构有不同的定义：
X64: #define GUARD_PAGE_SIZE (PAGE_SIZE * 2)
X86: #define GUARD_PAGE_SIZE PAGE_SIZE

这里便解释了为什么X86系统上的限制是4K(即PAGE_SIZE)，而X64上却为8K的原因。

说到此处，该是解答_chkstk()倒底是干什么的时候了。Visual Studio中有_chkstk的源码，以x86为例：

输入参数eax是所需堆栈大小（字节）
labelP _chkstk, PUBLIC

        push    ecx                          ; save ecx
        cmp     eax,_PAGESIZE_     ; more than one page requested?
        lea     ecx,[esp] + 8           ;   compute new stack pointer in ecx
                                                   ;   correct for return address and
                                                   ;   saved ecx
        jb      short lastpage           ; no

;------------

probepages:
sub ecx,_PAGESIZE_ ; yes, move down a page
sub eax,_PAGESIZE_ ; adjust request and...

test dword ptr [ecx],eax ; ...probe it (如果是guard page，刚会导致page fault，最终用户栈
; 将向下扩展一个页面)

cmp eax,_PAGESIZE_ ; more than one page requested?
jae short probepages ; no

lastpage:
sub ecx,eax ; move stack down by eax
mov eax,esp ; save current tos and do a...

        test    dword ptr [ecx],eax     ; ...probe in case a page was crossed
                                                        ; 调用函数将要访问的堆栈底部，如果此页面为guard page，同
                                                        ; 样会导致用户栈的向下延伸

mov esp,ecx ; set the new stack pointer
; 向下更改栈指针，其上直到原ESP的栈空间为调用函数局部变量

        mov     ecx,dword ptr [eax]     ; recover ecx
        mov     eax,dword ptr [eax + 4] ; recover return address
                                                            ; 将返回地址(调用函数中)放入eax

push eax ; prepare return address
; 将返回地址(调用函数中)放入当前栈中，准备返回

; ...probe in case a page was crossed
ret

end

_chkstk()的主要作用是保证栈向下连续的生长。如果没有_chkstk()，当局部变量太多并超过guard page下沿时，若再有压栈操作，将会导致Access violation错误。因为此时堆栈内存页面无效，压栈直接将导致page fault的发生，而page fault处理程序因不能识别此fault的发生原因从而不能做出正确判断和有效处理。

相对用户层，内核程序的处理则相当简单，就如Win7内核中_chkstk实际上就是个空函数。其原因就是内核线程的栈空间是固定的。其取值针对X86及X64架构亦有所不同：
X64： #define KERNEL_STACK_SIZE 0x6000 /* 6个内存页面 */
X86： #define KERNEL_STACK_SIZE 12288 /* 3个内存页面 */

内核中栈资源非常紧缺，并驱动程序的编写有较高的要求，特别是有递归的情况下，一定要注意嵌套的层数，否则很容易收到M$发来的蓝屏。

Windows内核中其实还有一种大堆栈机制，以确保一些对堆栈较高消耗的特殊情况能够得到满足，但这部分完全是黑箱，对用户不可见，不是常见情况，此处不再多述。

参考资料：
1, http://support.microsoft.com/kb/100775/en
2, http://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx
3, http://www.reactos.org ReactOS源码

再谈_chkstk

从_chkstk说起，谈谈用户栈的管理