Windows内核读书笔记——Windows异常分发处理机制

本篇读书笔记主要参考自《深入解析Windows操作系统》和《软件调试》这两本书。

IDT是处理异常,实现操作系统与CPU的交互的关口。

系统在初始化阶段会去填写这个结构。

IDT的每一个表项都成为门描述符,因为IDT的功能就像大门一样,从一个空间跳到另一个空间去执行。

IDT中包含三种门描述符

  • 任务门描述符:用于任务切换
  • 中断门描述符:用于描述中断处理例程
  • 陷阱们描述符:用于描述异常处理例程

CPU如何使用IDT

cpu首先根据IDTR找到IDT,再利用向量号码找到门描述符。再去判断门描述符的类型,如果是任务描述符,CPU会执行硬件方式的任务切换,切换到描述符所定义的线程。

但是CPU的PCR结构中也会保存有IDT的基地址,这个用处我没搞懂,可能与内核初始化流程有关系,以后再来研究。

如果是陷阱或中断描述符,那么会去调用处理例程。X64架构不支持硬件方式的任务切换,也就不再存在任务门了。

在调用处理例程之前,CPU会把EFLAGS、CS、EIP压入栈,如果发生的异常有错误代码则把错误代码也压入堆栈。

这个过程就是所谓的构建陷阱帧(Context)和异常记录(EXCEPTION_RECORD)

windows系统使用EXCEPTION_RECORD结构描述异常。

 typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode;//异常代码
DWORD ExceptionFlags;//异常标志
struct _EXCEPTION_RECORD *ExceptionRecord;//相关的另一个异常
PVOID ExceptionAddress;//异常发生的地址
DWORD NumberParameters;//参数数组中的参数个数
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];//参数数组
} EXCEPTION_RECORD, *PEXCEPTION_RECORD;

异常代码,可以认为是异常的别称,有的异常有异常代码有的则没有。

在经过中断或异常后会调用IDT中的处理例程比如KiTrap03,这个处理例程会调用CommonDispatchException函数。

CommonDispatchException函数会在栈中生成一个EXCEPTION_RECORD结构,把当前的数据情况写入到这个结构中。

然后会以这个结构为参数调用KiDispatchException来分发异常。

上面说的是硬件异常,接下来看看软件异常,软件异常是通过直接或间接调用内核函数NtRaiseException产生的,就是说软件异常不需要经过IDT分发等等这些东西只需要调用函数,而且用户层也可调用这个函数,用户层导出了一个RaiseException函数在kernel32.dll中,供用户产生一个自定义的异常。

RaiseException函数的实现原理是把相应的参数放入EXCEPTION_RECORD结构中,调用RtlRaiseException函数,这个函数把当前的线程上下文放入CONTEXT结构中,然后调用NtRaiseException。

NtRaiseException内部实现函数是KiRaiseException,我们看下面KiRaiseException的源码会发现这个函数还是调用 KiDispatchException来实现功能的。

   //来自WRK1.2
NTSTATUS
KiRaiseException (
IN PEXCEPTION_RECORD ExceptionRecord,//异常记录
IN PCONTEXT ContextRecord,//线程上下文结构
IN PKEXCEPTION_FRAME ExceptionFrame,//不使用,为空
IN PKTRAP_FRAME TrapFrame,//栈帧基地址
IN BOOLEAN FirstChance//表示是第一轮还是第二轮处理
) {
//省略了部分内容
//把ContextRecord复制到当前线程的内核栈中
KeContextToKframes(TrapFrame,
ExceptionFrame,
ContextRecord,
ContextRecord->ContextFlags,
PreviousMode);
//把异常记录中的异常代码最高位清零,这样可以分辨出软件异常和CPU异常
ExceptionRecord->ExceptionCode &= ~KI_EXCEPTION_INTERNAL;
//调用分发异常的函数
KiDispatchException(ExceptionRecord,
ExceptionFrame,
TrapFrame,
PreviousMode,
FirstChance); return STATUS_SUCCESS;
}

所有说无论是CPU异常还是软件异常都会调用KiDispatchException来分发异常。

异常分发过程

在Windows内核方面的圣经《Windows Internals》中有一部分章节是介绍Windows系统异常分发机制的,其实那一章节的内容就是在讲述KiDispatchException函数的处理流程(虽然作者根本没有提到这个函数,因为Windows内核是不开源的,微软也没有提供手册)。

第一次看《Windows Internals》时,我还没有读过这个函数的实现。当时对书里的各种概念如二次调试、寻找调试器等等一脸懵逼。但是看了这个函数之后会发现真正的处理流程是很清晰的。

首先异常有两大类,发生在内核态下的异常和发生在用户态下的异常。为什么要分两种,这两者是不一样的。

    if (PreviousMode == KernelMode)
{
//……
}
else
{
//……
}

函数一开始就把执行的流程完全的分成两部分了,可见内核异常与用户异常的分发是你走你的阳关道我走我的独木桥,两者是毫不关联的。

至于为什么要分为两个完全不同的流程,我想了一下用户态异常分发和内核态异常分发的相同点和不同点。

首先说说相同点:

1.都是基于二次调试机制

没有接触过异常分发的读者可能不明白什么叫二次调试机制。其实我们平时使用OD或是Windbg处理异常时就已经接触到二次调试机制了。比如,你用OD加载一个用户态程序,你就会接收到两次中断到调试器。其实这个是很常见的,尤其是以前玩CrackMe的时候经常可以碰到用触发异常来进行反调试的。这个时候如果你使用OD来忽略异常要连续忽略两次,这就是二次调试。

下面来做一个实验。

很简单的一个程序

 #include "stdio.h"

 int main()
{
int num = / ;
printf("%d", num);
return ;
}

触发一个除零异常

Windows内核读书笔记——Windows异常分发处理机制

VS2015编译不了这个,因为把除零视为错误了,不知道该怎么关这个保护机制。于是用C-Free 5编译了一下。运行后就是标准的Windows异常窗口,问你要不要挂载调试器啊什么的,这个选项是可以在注册表里面改的,下面也会研究一下这个标准的Windows异常窗口是哪里来的。这里先回归主题说一下二次调试的事情。

OD设置不忽略所有的异常,注意有SrongOD插件的要把插件关了。这样OD就不会忽略异常了,如果你用shift+F8来跳过这个异常,你会发现你要按两次shift+F8这个就是异常的二次调试。其实用Windbg可以更直观的看到二次调试的现象,用Windbg加载这个示例程序,按G继续,可以看到如图的情况

Windows内核读书笔记——Windows异常分发处理机制

这个就是二次调试。正如我们所说的,这是内核态异常分发和用户态异常分发的共同点,两者都会有二次调试。我个人认为这是一种保护机制,是一种“再给一次机会”的机制,就算没有这个二次调试机制也是无关大局的。

2.都在寻找调试器

我们知道异常是无法被“自动”处理的,举个例子,以上面那个例子程序来说,如果你不是手动指定异常处理代码(如__try)的话,那么异常是不可能自己消失的。就是说系统不会自己改错,当然也有例外的情况,比如说缺页异常就是自己处理的,应该是在中断处理例程中就处理完毕了,不会进行异常分发。但是那个是系统故意留的,根本不能称作是真正意义上的异常。

那么,所谓的异常分发就是一个寻找调试器和异常处理代码的过程。这个才是本质,也是分发的目的,找不到就进行暴力结束机制。因为不可能带着错误继续运行下去。

相同点说完了,那么重点就是不同点了。

不同点:

1.CPU模式的切换

我们前面说了,无论是在用户态触发异常还是在内核态触发异常都会调用到这个KiDispatchException函数,就是说当用户态触发异常后需要转入内核态。这好像是一句废话,因为很多函数都是要从用户态转入内核态的啊。比如用户层的CreateFile就会到内核层的NtCreateFile函数。但是对于用户态异常分发来说却不是这么简单,因为要执行用户态的用户指定的异常处理代码,所以进入这个KiDispatchException函数后还要再转回用户态去寻找用户态的异常处理代码。而对于内核异常分发来说是不需要CPU执行状态转来转去。

2.寻找调试器的函数不同

一个是寻找内核调试器的,一个是寻找用户态调试器的。这两者本质不同。

这个就是一个完整的流程图,来自《软件调试》

Windows内核读书笔记——Windows异常分发处理机制

上一篇:OpenGL ES 3.0 顶点缓冲区VBO使用


下一篇:Day18_集合第四天