1、内核与系统调用基础
对于应用程序进程来说，操作系统内核的作用体现在一组可供调用的函数，称为系统调用（也成"系统服务"）。
从程序运行的角度来看，进程是主动、活性的，是发出调用请求的一方；而内核是被动的，只是应进程要求而提供服务。从整个系统运行角度看，内核也有活性的一面，具体体现在进程调度。
系统调用所提供的服务(函数)是运行在内核中的，也就是说，在"系统空间"中。而应用软件则都在用户空间中，二者之间有着空间的间隔（CPU运行模式不同）。
综上所述，应用软件若想进行系统调用，则应用层和内核层之间，必须存在"系统调用接口"，即一组接口函数，这组接口运行于用户空间。对于Windows来说，其系统调用接口并不公开，公开是的一组对系统调用接口的封装函数，称为Windows API。
2、用户空间中的进程如何进行系统调用？
用户空间与系统空间所在的内存区间不一样，同样，对于这两种区间，CPU的运行状态也不一样。
在用户空间中，CPU处于"用户态"；在系统空间中，CPU处于"系统态"。
CPU从系统态进入用户态是容易的，因为可以执行一些系统态特有的特权指令，从而进入用户态。
而相反，用户态进入系统态则不容易，因为用户态是无法执行特权指令的。
所以，一般有三种手段，使CPU进入系统态（即转入系统空间执行）：
①中断：来自于外部设备的中断请求。当有中断请求到来时，CPU自动进入系统态，并从某个预定地址开始执行指令。中断只发生在两条指令之间，不影响正在执行的指令。
②异常：无论是在用户空间或系统空间，执行指令失败时都会引起异常，CPU会因此进入系统态（如果原先不在系统空间），从而在系统空间中对异常做出处理。异常发生在执行一条指令的过程中，所以当前执行的指令已经半途而废了。
③自陷：以上两种都CPU被动进入系统态。而自陷是CPU通过自陷指令主动进入系统态。多数CPU都有自陷指令，系统调用函数一般都是靠自陷指令实现的。一条自陷指令的作用相当于一次子程序调用，子程序存在于系统空间。
3、通过自陷指令调用系统服务流程：
windows系统通过自陷指令"int 0x2e"进入系统空间实现系统调用。
①CPU执行int 0x2e，CPU运行状态切换为系统态
②从任务状态段TSS装入本线程的系统空间的SS和ESP
③依次把用户空间的SS、ESP、EFLAGS、CS、EIP的内容压入系统空间堆栈
每个线程都有自己的系统空间堆栈,其堆栈段寄存器SS和堆栈指针ESP的内容保存在一个称为"任务状态段"既TSS的数据结构里面。与此相应，CPU中有个称为"任务寄存器"既TR的段寄存器。每当从用户空间进入系统空间时，CPU就自动根据TR的指引从TSS中获取当前进程的SS和ESP两个寄存器的值。然后在把上面提到的几个寄存器中的内容压入这个堆栈。当然，还要根据IDTR即中断描述符表寄存器的指引获取CS和EIP。这个过程所涉及的"时钟周期"显然不会少。正因为这样，后来才有了"快速系统调用"指令sysenter和sysexit的出现。
④从中断向量表中(Interrupt Descriptor Table)以0x2e为中断向量，开始执行系统空间中的程序。
⑤程序执行后，通过iret(中断返回)指令实现上述过程的逆过程
以ReadFile函数为例说明系统调用的整个过程：
Windows应用程序通过Win32 API调用这个界面所定义的库函数，这些库函数基本都是在DLL中定义的，比如kernel32.dll。运用Dependency Walker我们可以看到ReadFile在kernel32.dll里面。这个WIN32 API函数在ReactOS中也有定义，在./include/psdk/winbase.h里面。
BOOL WINAPI ReadFile(HANDLE,PVOID,DWORD,PDWORD,LPOVERLAPPED);
ReadFile函数的源码微软自然没有公布了，我们采用ReactOS的开源实现。
BOOL WINAPI
ReadFile(IN HANDLE hFile,
IN LPVOID lpBuffer,
IN DWORD nNumberOfBytesToRead,
OUT LPDWORD lpNumberOfBytesRead OPTIONAL,
IN LPOVERLAPPED lpOverlapped OPTIONAL)
{
NTSTATUS Status;
TRACE("ReadFile(hFile %p)\n", hFile);
if (lpNumberOfBytesRead != NULL) *lpNumberOfBytesRead = 0;
if (!nNumberOfBytesToRead) return TRUE;
hFile = TranslateStdHandle(hFile);
if (IsConsoleHandle(hFile))
{
if (ReadConsoleA(hFile,
lpBuffer,
nNumberOfBytesToRead,
lpNumberOfBytesRead,
NULL))
{
DWORD dwMode;
GetConsoleMode(hFile, &dwMode);
if ((dwMode & ENABLE_PROCESSED_INPUT) && *(PCHAR)lpBuffer == 0x1a)
{
/* EOF字符输入; 模拟文件结束 */
*lpNumberOfBytesRead = 0;
}
return TRUE;
}
return FALSE;
}
if (lpOverlapped != NULL)
{
LARGE_INTEGER Offset;
PVOID ApcContext;
Offset.u.LowPart = lpOverlapped->Offset;
Offset.u.HighPart = lpOverlapped->OffsetHigh;
lpOverlapped->Internal = STATUS_PENDING;
ApcContext = (((ULONG_PTR)lpOverlapped->hEvent & 0x1) ? NULL : lpOverlapped);
Status = NtReadFile(hFile,
lpOverlapped->hEvent,
NULL,
ApcContext,
(PIO_STATUS_BLOCK)lpOverlapped,
lpBuffer,
nNumberOfBytesToRead,
&Offset,
NULL);
/* 在失败或挂起操作时, 返回FALSE! */
if (!NT_SUCCESS(Status) || Status == STATUS_PENDING)
{
if (Status == STATUS_END_OF_FILE && lpNumberOfBytesRead != NULL)
*lpNumberOfBytesRead = 0;
BaseSetLastNTError(Status);
return FALSE;
}
if (lpNumberOfBytesRead != NULL)
*lpNumberOfBytesRead = lpOverlapped->InternalHigh;
}
else
{
IO_STATUS_BLOCK Iosb;
Status = NtReadFile(hFile,
NULL,
NULL,
NULL,
&Iosb,
lpBuffer,
nNumberOfBytesToRead,
NULL,
NULL);
/* 当执行挂起操作时等待 */
if (Status == STATUS_PENDING)
{
Status = NtWaitForSingleObject(hFile, FALSE, NULL);
if (NT_SUCCESS(Status)) Status = Iosb.Status;
}
if (Status == STATUS_END_OF_FILE)
{
/*
* 这里lpNumberOfBytesRead不必须是NULL, 实际上Win也不会检查这种情形，
* 仅在操作完成之后崩溃。
*/
*lpNumberOfBytesRead = 0;
return TRUE;
}
if (NT_SUCCESS(Status))
{
/*
* 这里lpNumberOfBytesRead不必须是NULL, 实际上Win也不会检查这种情形，
* 仅在操作完成之后崩溃。
*/
*lpNumberOfBytesRead = Iosb.Information;
}
else
{
BaseSetLastNTError(Status);
return FALSE;
}
}
TRACE("ReadFile() succeeded\n");
return TRUE;
}
ReadFile函数体内会调用NtReadFile函数，NtReadFile函数是Windows的一个系统调用。该函数的实现在ntoskrnl.exe中。但是ReadFile运行在用户空间，而NtReadFile运行在内核空间，用户空间不可能直接调用内核空间的函数。因此，在用户空间中还存在一个也叫NtReadFile的中介函数。这部分在最新的ReactOS应该是通过一个工具实现的。所谓的工具应该是汇编代码。我认为调用中介的实现在./include/asm/syscalls.inc中，具体代码如下，以x86为例：#ifdef _M_IX86
#define KUSER_SHARED_SYSCALL HEX(7ffe0300)
#define KGDT_R0_CODE 8
MACRO(STUBCODE_U, Name, SyscallId, ArgCount)
StackBytes = 4 * ArgCount
FPO 0, 0, 0, 0, 0, FRAME_FPO
mov eax, SyscallId
mov ecx, KUSER_SHARED_SYSCALL
call dword ptr [ecx]
ret StackBytes
ENDM
MACRO(STUBCODE_K, Name, SyscallId, ArgCount)
StackBytes = 4 * &ArgCount
FPO 0, 0, 0, 0, 0, FRAME_FPO
mov eax, SyscallId
lea edx, [esp + 4]
pushfd
push KGDT_R0_CODE
call _KiSystemService
ret StackBytes
ENDM
#elif defined(_M_AMD64)
...
#elif defined(_M_ARM)
...
#elif defined(_M_PPC)
...
#elif defined(_M_MIPS)
...
#else
#error unsupported architecture
#endif
在The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System书中，有一个dd.exe调用I/O管理器的图示：
我们不难看出这个过程中调用的NtReadFile是在ntdll.dll中导出的，存在于用户空间内，通过了快速系统调用来完成对内核中NtReadFile的调用。和《Windows内核情景分析》中分析的基本相同。KUSER_SHARED_SYSCALL返回的函数指针(7ffe0300)取决于CPU是否支持KiFastSystemCall或KiIntSystemCall。
关于这一点将在下一篇日志中有所描述。
( 粤ICP备18085999号-1 | 粤公网安备 44051102000585号)
