漫谈兼容内核之一:
ReactOS怎样实现系统调用
毛德操
有网友在论坛上发贴，要求我谈谈ReactOS是怎样实现系统调用的。另一方面，我上次已经谈到兼容内核应该如何实现Windows系统调用的问题，接着谈谈ReactOS怎样实现系统调用倒也顺理成章，所以这一次就来谈谈这个话题。不过这显然不属于“漫谈Wine”的范畴，也确实没有必要再来个“漫谈ReactOS”，因此决定把除Wine以外的话题都纳入“漫谈兼容内核”。
ReactOS这个项目的目标是要开发出一个开源的Windows。不言而喻，它要实现的系统调用就是Windows的那一套系统调用，也就是要忠实地实现Windows系统调用界面。本文要说的不是Windows系统调用界面本身，而是ReactOS怎样实现这个界面，主要是说说用户空间的应用程序怎样进入/退出内核、即系统空间，怎样调用定义于这个界面的函数。实际上，ReactOS正是通过“int 0x2e”指令进入内核、实现系统调用的。虽然ReactOS并不是Windows，它的作者们也未必看到过Windows的源代码；但是我相信，ReactOS的代码、至少是这方面的代码，与“正本”Windows的代码应该非常接近，要有也只是细节上的差别。
下面以系统调用NtReadFile()为例，按“自顶向下”的方式，一方面说明怎样阅读ReactOS 的代码，一方面说明ReacOS是怎样实现系统调用的。
首先，Windows应用程序应该通过Win32 API调用这个接口所定义的库函数，这些库函数基本上都是在“动态连接库”、即DLL中实现的。例如，ReadFile()就是在Win32 API 中定义的一个库函数。实现这个库函数的可执行程序在Windows的“系统DLL”之一kernel32.dll中，有兴趣的读者可以在Windows上用一个工具打开kernel32.dll，就可以看到这个DLL的导出函数表中有ReadFile()。另一方面，在微软的VC开发环境(Visual Studio)中、以及Win2k DDK中，都有个“头文件”winbase.h，里面有ReadFile()的接口定义：
WINBASEAPI
BOOL
WINAPI
ReadFile(
IN HANDLE hFile,
OUT LPVOID lpBuffer,
IN DWORD nNumberOfBytesToRead,
OUT LPDWORD lpNumberOfBytesRead,
IN LPOVERLAPPED lpOverlapped
);
函数名前面的关键词WINAPI表示这是个定义于Win32 API的函数。
在ReactOS的代码中同样也有winbase.h，这是在目录reactos/w32api/include中：BOOL WINAPI ReadFile(HANDLE, PVOID, DWORD, PDWORD, LPOVERLAPPED);
显然，这二者实际上是相同的(要不然就不兼容了)。当然，微软没有公开这个函数的代码，但是ReactOS为之提供了一个开源的实现，其代码在reactos/lib/kernel32/file/rw.c中。
BOOL STDCALL
ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverLapped )
{
…
…
errCode = NtReadFile(hFile,
hEvent,
NULL,
NULL,
IoStatusBlock,
lpBuffer,
nNumberOfBytesToRead,
ptrOffset,
NULL);
……
react to do
return(TRUE);
}
我们在这里只关心NtReadFile()，所以略去了别的代码。
如前所述，NtReadFile()是Windows的一个系统调用，内核中有个函数就叫NtReadFile()，它的实现在中(这是Windows内核的核心部分)，这也可以用打开察看。ReactOS代码中对内核函数NtReadFile()的定义在reactos/include/ntos/zw.h 中，同样的定义也出现在reactos/w32api/include/ddk/winddk.h中：
NTSTATUS
STDCALL
NtReadFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE UserApcRoutine OPTIONAL,
IN PVOID UserApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG BufferLength,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);
而相应的实现则在reactos/ntoskrnl/io/rw.c中。
表面上看这似乎挺正常，ReadFile()调用NtReadFile()，reactos/ntoskrnl/io/rw.c则为其提供了被调用的NtReadFile()。可是仔细一想就不对了。这ReadFile()是在用户空间运行的，而reactos/ntoskrnl/io/rw.c中的代码却是在内核中，是在系统空间。难道用户空间的程序竟能如此这般地直接调用内核中的函数吗？
如果那样的话，那还要什么陷阱门、调用门这些机制呢？再说，编译的时候又怎样把它们连接起来呢？
这么一想，就可以断定这里面另有奥妙。仔细一查，原来还另有一个NtReadFile()，在msvc6/iface/native/syscall/Debug/zw.c中：
__declspec(naked) __stdcall
NtReadFile(int dummy0, int dummy1, int dummy2)
{
__asm {
push ebp
mov ebp, esp
mov eax,152
lea edx, 8[ebp]
int 0x2E
pop ebp
ret 9
}
}
原来，用户空间也有一个NtReadFile()，正是这个函数在执行自陷指令“int 0x2e”。我们看一下这段汇编代码。这里面的152就是NtReadFile()这个系统调用的调用号，所以当CPU 自陷进入系统空间后寄存器eax持有具体的系统调用号。而寄存器edx，在执行了lea这条指令以后，则持有CPU在调用这个函数前夕的堆栈指针，实际上就是指向堆栈中调用参数的起点。在进行系统调用时如何传递参数这个问题上，Windows和Linux有着明显的差别。我们知道，Linux是通过寄存器传递参数的，好处是效率比较高，但是参数的个数受到了限制，所以Linux系统调用的参数都很少，真有大量参数需要传递时就把它们组装在数据结构中，而只传递数据结构指针。而Windows则通过堆栈传递参数。读者在上面看到，ReadFile()在调用NtReadFile()时有9个参数，这9个参数都被压入堆栈，而edx就指向堆栈中的这些参数的起点(地址最低处)。我们在这个函数中没有看到对通过堆栈传下来的参数有什么操作，也没有看到往堆栈里增加别的参数，所以传下来的9个参数被原封不动地传了下去(作为int 0x2e自陷的参数)。这样，当CPU自陷进入内核以后，edx仍指向用户空间堆栈中的这些参数。当然，CPU进入内核以后的堆栈是系统空间堆
栈，而不是用户空间堆栈，所以需要用copy_from_user()一类的函数把这些参数从用户空间拷贝过来，此时edx的值就可用作源指针。至于寄存器ebp，则用作调用这个函数时的“堆栈框架”指针。
当内核完成了具体系统调用的操作，CPU返回到用户空间时，下一条指令是“pop ebp”，即恢复上一层函数的堆栈框架指针。然后，指令“ret 9”使CPU返回到上一层函数，同时调整堆栈指针，使其跳过堆栈上的9个调用参数。在“正宗”的x86汇编语言中，用在ret 指令中的数值以字节为单位，所以应该是“ret 24h”，而这里却是以4字节长字为单位，这显然是因为用了不同的汇编工具。
子程序的调用者可以把参数压入堆栈，通过堆栈把参数传递给被调用者。可是，当CPU
从子程序返回时，由谁负责从堆栈中清除这些参数呢？显然，要么就是由调用者负责，要么就是由被调用者负责，这里需要有个约定，使得调用者和被调用者取得一致。在上面NtReadFile()这个函数中，我们看到是由被调用者负起了这个责任、在调整堆栈指针。函数代码前面的__stdcall就说明了这一点。同样，在.件中对NtReadFile()的定义(申明)之前也加上了STDCALL，也是为了说明这个约定。“Undocumented Windows 2000 Secrets”这本书中(p51-53)对类似的各种约定有一大段说明，读者可以参考。另一方面，在上面这个函数的代码中，函数的调用参数是3个而不是9个。但是看一下代码就可以知道这些参数根本就没有被用到，而调用者、即前面的ReadFile()、也是按9个参数来调用NtReadFile()的。所以，这里的三个参数完全是虚设的，有没有、或者有几个、都无关紧要，难怪代码中称之为“dummy”。
用户空间的这个NtReadFile()向上代表着内核函数NtReadFile()，向下则代表着想要调用内核函数NtReadFile()的那个函数，在这里是ReadFile()；但是它本身并不提供什么附加的功能，这样的中间函数称为“stub”。
当然，ReactOS的这种做法很容易把读者引入迷茫。相比之下，Linux的做法就比较清晰，例如应用程序调用的是库函数write()，而内核中与之对应的函数则是sys_write()。
那么为什么ReactOS要这么干呢？我只能猜测：
1）Windows的源代码中就是这样，例如用在ntdll.dll和中都可看到有名为NtReadFile()的函数，而ReactOS的人就依葫芦画瓢。
2）作为一条开发路线，ReactOS可能在初期不划分用户空间和系统空间，所有的代码全在同一个空间运行，所以应用程序可以直接调用内核中的函数。这样，例
如对文件系统的开发就可以简单易行一些。然后，到一些主要的功能都开发出
来以后，再来划分用户空间和系统空间，并且补上如何跨越空间这一层。从zw.c
这个文件在native/syscall/Debug目录下这个迹象看，ReactOS似乎正处于走出这
一步的过程中。
3）ReactOS的作者们可能有意让它也可以用于嵌入式系统。嵌入式系统往往不划分用户空间和系统空间，而把应用程序和内核连接在同一个可执行映像中。这样，
如果需要把代码编译成一个嵌入式系统，就不使用stub；而若要把代码编译成一
个桌面系统，则可以在用户空间加上stub并在内核中加上处理自陷指令“int
0x2e”的程序。
在Windows中，stub函数NtReadFile()在ntdll.dll中。实际上，所有0x2e系统调用的stub 函数都在这个DLL中。显然，所有系统调用的stub函数具有相同的样式，不同的只是系统调用号和参数的个数，所以ReactOS用一个工具来自动生成这些stub函数。这个工具的代码在msvc6/iface/native/genntdll.c中，下面是一个片断：
void write_syscall_stub(FILE* out, FILE* out3, char* name, char* name2,
char* nr_args, unsigned int sys_call_idx)
{
int i;
int nArgBytes = atoi(nr_args);
#ifdef PARAMETERIZED_LIBS
……
#else
fprintf(out,"__asm__(\"\\n\\t.global _%s\\n\\t\"\n",name);
fprintf(out,"\".global _%s\\n\\t\"\n",name2);
fprintf(out,"\"_%s:\\n\\t\"\n",name);
fprintf(out,"\"_%s:\\n\\t\"\n",name2);
#endif
fprintf(out,"\t\"pushl\t%%ebp\\n\\t\"\n");
fprintf(out,"\t\"movl\t%%esp, %%ebp\\n\\t\"\n");
fprintf(out,"\t\"mov\t$%d,%%eax\\n\\t\"\n",sys_call_idx);
fprintf(out,"\t\"lea\t8(%%ebp),%%edx\\n\\t\"\n");
fprintf(out,"\t\"int\t$0x2E\\n\\t\"\n");
fprintf(out,"\t\"popl\t%%ebp\\n\\t\"\n");
fprintf(out,"\t\"ret\t$%s\\n\\t\");\n\n",nr_args);
……
}
代码中的’\t’表示TAB字符，读者阅读这段代码应该没有什么问题。这段代码根据name、nr_args、sys_call_idx等参数为给定系统调用生成stub函数的汇编代码。那么这些参数从何而来呢？在ReactOS代码的reactos/tools/nci目录下有个文件sysfuncs.lst，下面是从这个文件中摘出来的几行：
NtAcceptConnectPort 6
NtAccessCheck 8
NtAccessCheckAndAuditAlarm 11
NtAddAtom 3
……
NtClose 1
……
NtReadFile 9
……
这里的NtAcceptConnectPort就是调用号为0的系统调用NtAcceptConnectPort()，它有6个参数。另一个系统调用NtClose()只有1个参数。而NtReadFile()有9个参数，并且正好是这个表中的第153行，所以调用号是152。
用户空间的程序一执行int 0x2e，CPU就自陷进入了系统空间。其间的物理过程这里就不多说了，有需
要的读者可参考“情景分析”或其它有关资料。我这里就从CPU怎样进入int 0x2e的自陷处理程序说起。
像别的中断向量一样，ReactOS在其初始化程序KeInitExceptions()中设置了int 0x2e的向量，这个函数的代码在reactos/ntoskrnl/ke/i386/exp.c中：
VOID INIT_FUNCTION
KeInitExceptions(VOID)
/*
* FUNCTION: Initalize CPU exception handling

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。