[6]Windows内核情景分析 --APC
APC：异步过程调用。这是一种常见的技术。前面进程启动的初始过程就是：主线程在内核构造好运行环境后，从KiThreadStartup开始运行，然后调用PspUserThreadStartup，在该线程的apc队列中插入一个APC：LdrInitializeThunk,这样，当PspUserThreadStartup返回后，正式退回用户空间的总入口BaseProcessStartThunk前，会执行中途插入的那个apc，完成进程的用户空间初始化工作（链接dll的加载等）
可见：APC的执行时机之一就是从内核空间返回用户空间的前夕。也即在返回用户空间前，会“中断”那么一下。因此，APC就是一种软中断。
除了这种APC用途外，应用程序中也经常使用APC。如Win32 API ReadFileEx就可以使用APC机制来实现异步读写文件的功能。
BOOL //源码
ReadFileEx(IN HANDLE hFile,
IN LPVOID lpBuffer,
IN DWORD nNumberOfBytesToRead OPTIONAL,
IN LPOVERLAPPED lpOverlapped,//完成结果
IN LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine)//预置APC将调用的完成例程
{
LARGE_INTEGER Offset;
NTSTATUS Status;
Offset.u.LowPart = lpOverlapped->Offset;
Offset.u.HighPart = lpOverlapped->OffsetHigh;
lpOverlapped->Internal = STATUS_PENDING;
Status = NtReadFile(hFile,
NULL, //Event=NULL
ApcRoutine,//这个是内部预置的APC例程
lpCompletionRoutine,//APC的Context
(PIO_STATUS_BLOCK)lpOverlapped,
lpBuffer,
nNumberOfBytesToRead,
&Offset,
NULL);//Key=NULL
if (!NT_SUCCESS(Status))
{
SetLastErrorByStatus(Status);//
return FALSE;
}
return TRUE;
}
VOID ApcRoutine(PVOID ApcContext,//指向用户提供的完成例程
_IO_STATUS_BLOCK* IoStatusBlock,//完成结果
ULONG Reserved)
{
LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine = ApcContext;
DWORD dwErrorCode = RtlNtStatusToDosError(IoStatusBlock->Status);
//调用用户提供的完成例程
lpCompletionRoutine(dwErrorCode,
IoStatusBlock->Information,
(LPOVERLAPPED)IoStatusBlock);
}
因此，应用层的用户提供的完成例程实际上是作为APC函数进行的，它运行在APC_LEVEL irql
NTSTATUS
NtReadFile(IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,//内置的APC
IN PVOID ApcContext OPTIONAL,//应用程序中用户提供的完成例程
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL)
{
…
Irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);//分配一个irp
Irp->Overlay.AsynchronousParameters.UserApcRoutine = ApcRoutine;//记录
Irp->Overlay.AsynchronousParameters.UserApcContext = ApcContext;//记录
…
Status = IoCallDriver(DeviceObject, Irp);//把这个构造的irp发给底层驱动
…
}
当底层驱动完成这个irp后，会调用IoCompleteRequest完成掉这个irp，这个IoCompleteRequest实际上内部最终调用IopCompleteRequest来做一些完成时的工作
VOID
IopCompleteRequest(IN PKAPC Apc,
IN PKNORMAL_ROUTINE* NormalRoutine,
IN PVOID* NormalContext,
IN PVOID* SystemArgument1,
IN PVOID* SystemArgument2)
{
…
if (Irp->Overlay.AsynchronousParameters.UserApcRoutine)//上面传入的APC
{
//构造一个APC
KeInitializeApc(&Irp->Tail.Apc,KeGetCurrentThread(),CurrentApcEnvironment,
IopFreeIrpKernelApc,
IopAbortIrpKernelApc,
(PKNORMAL_ROUTINE)Irp->Overlay.AsynchronousParameters.UserApcRoutine,
Irp->RequestorMode,
Irp->Overlay.AsynchronousParameters.UserApcContext);//应用层的完成例程
//插入到APC队列
KeInsertQueueApc(&Irp->Tail.Apc, Irp->UserIosb, NULL, 2);
}//end if
…
}
如上，ReadFileEx函数的异步APC机制是：在这个请求完成后，IO管理器会将一个APC插入队列中，然后
在返回用户空间前夕调用那个内置APC，最终调用应用层用户提供的完成例程。
明白了APC大致原理后，现在详细看一下APC的工作原理。
APC分两种，用户APC、内核APC。前者指在用户空间执行的APC，后者指在内核空间执行的APC。
先看一下内核为支持APC机制提供的一些基础结构设施。
Typedef struct _KTHREAD
{
…
KAPC_STATE ApcState;//表示本线程当前使用的APC状态（即apc队列的状态）
KAPC_STATE SavedApcState;//表示保存的原apc状态，备份用
KAPC_STATE* ApcStatePointer[2];//状态数组，包含两个指向APC状态的指针
UCHAR ApcStateIndex;//0或1，指当前的ApcState在ApcStatePointer数组中的索引位置
UCHAR ApcQueueable;//指本线程的APC队列是否可插入apc
ULONG KernelApcDisable;//禁用标志
//专用于挂起操作的APC（这个函数在线程一得到调度就重新进入等待态,等待挂起计数减到0）
KAPC SuspendApc;
…
}KTHREAD;
Typedef struct _KAPC_STATE //APC队列的状态描述符
{
LIST_EBTRY ApcListHead[2];//每个线程有两个apc队列
PKPROCESS Process;//当前线程所在的进程
BOOL KernelApcInProgress;//指示本线程是否当前正在 内核apc
BOOL KernelApcPending;//表示内核apc队列中是否有apc
BOOL UserApcPending;//表示用户apc队列中是否apc
}
Typedef enum _KAPC_ENVIRONMENT
{
OriginalApcEnvironment,//0，状态数组索引
AttachedApcEnvironment;//1，状态数组索引
CurrentApc Environment;//2，表示使用当前apc状态
CurrentApc Environment;//3，表示使用插入apc时那时的线程的apc状态
}
一个线程可以挂靠到其他进程的地址空间中，因此，一个线程的状态分两种：常态、挂靠态。
常态下，状态数组中0号元素指向ApcState(即当前apc状态)，1号元素指向SavedApcState(非当前apc状态)；挂靠态下，两个元素的指向刚好相反。但无论如何，KTHREAD结构中的ApcStateIndex总是指当前状态的位置，ApcState则总是表示线程当前使用的apc状态。
于是有：
#define PsGetCurrentProcess IoGetCurrentProces
PEPROCESS IoGetCurrentProces()
{
Return PsGetCurrentThread()->Tcb.ApcState.Process;//ApcState中的进程字段总是表示当前进程
}
不管当前线程是处于常态还是挂靠态下，它都有两个apc队列，一个内核，一个用户。把apc插入对应的队列后就可以在恰当的时机得到执行。注意：每当一个线程挂靠到其他进程时，挂靠初期，两个apc队列都会变空。下面看下每个apc本身的结构
typedef struct _KAPC
{
UCHAR Type;//结构体的类型
UCHAR Size;//结构体的大小
struct _KTHREAD *Thread;//目标线程
LIST_ENTRY ApcListEntry;//用来挂入目标apc队列
PKKERNEL_ROUTINE KernelRoutine;//该apc的内核总入口
PKRUNDOWN_ROUTINE RundownRoutine;
PKNORMAL_ROUTINE NormalRoutine;//该apc的用户空间总入口或者用户真正的内核apc函数
PVOID NormalContext;//真正用户提供的用户空间apc函数或者用户真正的内核apc函数的context*
PVOID SystemArgument1;//挂入时的附加参数1。真正用户apc的context*
PVOID SystemArgument2;//挂入时的附加参数2
CCHAR ApcStateIndex;//指要挂入目标线程的哪个状态时的apc队列
KPROCESSOR_MODE ApcMode;//指要挂入用户apc队列还是内核apc队列
BOOLEAN Inserted;//表示本apc是否已挂入队列
} KAPC, *PKAPC;
注意：
若这个apc是内核apc，那么NormalRoutine表示用户自己提供的内核apc函数，NormalContext则是该apc函数的context*，SystemArgument1与SystemArgument2表示插入队列时的附加参数
若这个apc是用户apc，那么NormalRoutine表示该apc的用户空间总apc函数，NormalContext才是真正用户自己提供的用户空间apc函数，SystemArgument1则表示该真正apc的context*。（一切错位了）
//下面这个Win32 API可以用来手动插入一个apc到指定线程的用户apc队列中
DWORD
QueueUserAPC(PAPCFUNC pfnAPC, HANDLE hThread, ULONG_PTR dwData)
{
NTSTATUS Status;
//调用对应的系统服务
Status = NtQueueApcThread(hThread,//目标线程
IntCallUserApc,//用户空间中的总apc入口
pfnAPC,//用户自己真正提供的apc函数
(PVOID)dwData,//SysArg1=context*
NULL);//SysArg2=NULL
if (!NT_SUCCESS(Status))
{
SetLastErrorByStatus(Status);
return 0;
}
return 1;
}
NTSTATUS
NtQueueApcThread(IN HANDLE ThreadHandle,//目标线程
IN PKNORMAL_ROUTINE ApcRoutine,//用户空间中的总apc
IN PVOID NormalContext,//用户自己真正的apc函数
IN PVOID SystemArgument1,//用户自己apc的context*
IN PVOID SystemArgument2)//其它
{
PKAPC Apc;
PETHREAD Thread;
NTSTATUS Status = STATUS_SUCCESS;
Status = ObReferenceObjectByHandle(ThreadHandle,THREAD_SET_CONTEXT,PsThreadType,
ExGetPreviousMode(), (PVOID)&Thread,NULL);
//分配一个apc结构，这个结构最终在PspQueueApcSpecialApc中释放
Apc = ExAllocatePoolWithTag(NonPagedPool |POOL_QUOTA_FAIL_INSTEAD_OF_RAISE,
sizeof(KAPC),TAG_PS_APC);
//构造一个apc
KeInitializeApc(Apc,
&Thread->Tcb,//目标线程
OriginalApcEnvironment,//目标apc状态（此服务固定为OriginalApcEnvironment）
PspQueueApcSpecialApc,//内核apc总入口
NULL,//Rundown Rounine=NULL
ApcRoutine,//用户空间的总apc
UserMode,//此系统服务固定插入到用户apc队列
NormalContext);//用户自己真正的apc函数
//插入到目标线程的用户apc队列
KeInsertQueueApc(Apc,
SystemArgument1,//插入时的附加参数1，此处为用户自己apc的context*
SystemArgument2, //插入时的附加参数2
IO_NO_INCREMENT)//表示不予调整目标线程的调度优先级
return Status;
}
//这个函数用来构造一个要插入指定目标队列的apc对象
VOID
KeInitializeApc(IN PKAPC Apc,
IN PKTHREAD Thread,//目标线程
IN KAPC_ENVIRONMENT TargetEnvironment,//目标线程的目标apc状态
IN PKKERNEL_ROUTINE KernelRoutine,//内核apc总入口
IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
IN PKNORMAL_ROUTINE NormalRoutine,//用户空间的总apc
IN KPROCESSOR_MODE Mode,//要插入用户apc队列还是内核apc队列
IN PVOID Context) //用户自己真正的apc函数
{
Apc->Type = ApcObject;
Apc->Size = sizeof(KAPC);
if (TargetEnvironment == CurrentApcEnvironment)//CurrentApcEnvironment表示使用当前apc状态
Apc->ApcStateIndex = Thread->ApcStateIndex;
else
Apc->ApcStateIndex = TargetEnvironment;
Apc->Thread = Thread;
Apc->KernelRoutine = KernelRoutine;
Apc->RundownRoutine = RundownRoutine;
Apc->NormalRoutine = NormalRoutine;
if (NormalRoutine)//if 提供了用户空间总apc入口
{
Apc->ApcMode = Mode;
Apc->NormalContext = Context;
}
Else//若没提供，肯定是内核模式
{
Apc->ApcMode = KernelMode;
Apc->NormalContext = NULL;
}
Apc->Inserted = FALSE;//表示初始构造后，尚未挂入apc队列
}
BOOLEAN
KeInsertQueueApc(IN PKAPC Apc,IN PVOID SystemArgument1,IN PVOID SystemArgument2,
IN KPRIORITY PriorityBoost)
{
PKTHREAD Thread = Apc->Thread;
KLOCK_QUEUE_HANDLE ApcLock;
BOOLEAN State = TRUE;
KiAcquireApcLock(Thread, &ApcLock);//插入过程需要独占队列
if (!(Thread->ApcQueueable) || (Apc->Inserted))//检查队列是否可以插入apc
State = FALSE;
else
{
Apc->SystemArgument1 = SystemArgument1;//记录该apc的附加插入时的参数
Apc->SystemArgument2 = SystemArgument2; //记录该apc的附加插入时的参数
Apc->Inserted = TRUE;//标记为已插入队列
//插入目标线程的目标apc队列（如果目标线程正处于睡眠状态，可能会唤醒它）
KiInsertQueueApc(Apc, PriorityBoost);
}
KiReleaseApcLockFromDpcLevel(&ApcLock);
KiExitDispatcher(ApcLock.OldIrql);//可能引发一次线程切换，以立即切换到目标线程执行apc
return State;
}
VOID FASTCALL
KiInsertQueueApc(IN PKAPC Apc,IN KPRIORITY PriorityBoost)//唤醒目标线程后的优先级增量
{
PKTHREAD Thread = Apc->Thread;
BOOLEAN RequestInterrupt = FALSE;
if (Apc->ApcStateIndex == InsertApcEnvironment) //if要动态插入到当前的apc状态队列
Apc->ApcStateIndex = Thread->ApcStateIndex;
ApcState = Thread->ApcStatePointer[(UCHAR)Apc->ApcStateIndex];//目标状态
ApcMode = Apc->ApcMode;
//先插入apc到指定位置
/* 插入位置的确定：分三种情形
* 1) Kernel APC with Normal Routine or User APC : Put it at the end of the List
* 2) User APC which is PsExitSpecialApc : Put it at the front of the List
* 3) Kernel APC without Normal Routine : Put it at the end of the No-Normal Routine Kernel APC list
*/
if (Apc->NormalRoutine)//有NormalRoutine的APC都插入尾部（用户模式发来的线程终止APC除外）
{
if ((ApcMode == UserMode) && (Apc->KernelRoutine == PsExitSpecialApc))
{
Thread->ApcState.UserApcPending = TRUE;
InsertHeadList(&ApcState->ApcListHead[ApcMode],&Apc->ApcListEntry);
}
else
InsertTailList(&ApcState->ApcListHead[ApcMode],&Apc->ApcListEntry);
}
Else //无NormalRoutine的特殊类APC（内核APC），少见
{
ListHead = &ApcState->ApcListHead[ApcMode];
NextEntry = ListHead->Blink;
while (NextEntry != ListHead)
{
QueuedApc = CONTAINING_RECORD(NextEntry, KAPC, ApcListEntry);
if (!QueuedApc->NormalRoutine) break;
NextEntry = NextEntry->Blink;
}
InsertHeadList(NextEntry, &Apc->ApcListEntry);//插在这儿
}
//插入到相应的位置后，下面检查Apc状态是否匹配
if (Thread->ApcStateIndex == Apc->ApcStateIndex)//if 插到了当前apc状态的apc队列中
{
if (Thread == KeGetCurrentThread())//if就是给当前线程发送的apc
{
ASSERT(Thread->State == Running);//当前线程肯定没有睡眠，这不废话吗？
if (ApcMode == KernelMode)
{
Thread->ApcState.KernelApcPending = TRUE;
if (!Thread->SpecialApcDisable)//发出一个apc中断，待下次降低irql时将执行apc
HalRequestSoftwareInterrupt(APC_LEVEL); //关键
}
}
Else //给其他线程发送的内核apc
{
KiAcquireDispatcherLock();
if (ApcMode == KernelMode)
{
Thread->ApcState.KernelApcPending = TRUE;
if (Thread->State == Running)
RequestInterrupt = TRUE;//需要给它发出一个apc中断
else if ((Thread->State == Waiting) && (Thread->WaitIrql == PASSIVE_LEVEL) &&
!(Thread->SpecialApcDisable) && (!(Apc->NormalRoutine) ||
(!(Thread->KernelApcDisable) &&
!(Thread->ApcState.KernelApcInProgress))))
{
Status = STATUS_KERNEL_APC;
KiUnwaitThread(Thread, Status, PriorityBoost);//临时唤醒目标线程执行apc
}
else if (Thread->State == GateWait) …
}
else if ((Thread->State == Waiting) && (Thread->WaitMode == UserMode) &&
((Thread->Alertable) || (Thread->ApcState.UserApcPending)))
{
Thread->ApcState.UserApcPending = TRUE;
Status = STATUS_USER_APC;
KiUnwaitThread(Thread, Status, PriorityBoost);//强制唤醒目标线程
}
KiReleaseDispatcherLockFromDpcLevel();
KiRequestApcInterrupt(RequestInterrupt, Thread->NextProcessor);
}
}
}
如上，这个函数既可以给当前线程发送apc，也可以给目标线程发送apc。若给当前线程发送内核apc时，会立即请求发出一个apc中断。若给其他线程发送apc时，可能会唤醒目标线程。
APC函数的执行时机：
回顾一下从内核返回用户时的流程：
KiSystemService()//int 2e的isr，内核服务函数总入口，注意这个函数可以嵌套、递归！！！
{
SaveTrap();//保存trap现场
Sti //开中断
---------------上面保存完寄存器等现场后，开始查SST表调用系统服务------------------
FindTableCall();
---------------------------------调用完系统服务函数后------------------------------
Move esp,kthread.TrapFrame; //将栈顶回到trap帧结构体处
Cli //关中断
If(上次模式==UserMode)
{
Call KiDeliverApc //遍历执行本线程的内核APC和用户APC队列中的所有APC函数
清理Trap帧，恢复寄存器现场
Iret //返回用户空间
}
Else
{
返回到原call处后面的那条指令处
}
}
不光是从系统调用返回用户空间要扫描执行apc，从异常和中断返回用户空间也同样需要扫描执行。
现在我们只看从系统调用返回时apc的执行过程。
上面是伪代码，实际的从Cli后面的代码，是下面这样的。
Test dword ptr[ebp+KTRAP_FRAME_EFLAGS], EFLAGS_V86_MASK //检查eflags是否标志运行在V86模式
Jnz 1 //若运行在V86模式，那么上次模式肯定是从用户空间进入内核的，跳过下面的检查
Test byte ptr[ebp+KTRAP_FRAME_CS],1
Je 2 //若上次模式不是用户模式，跳过下面的流程，不予扫描apc
1:
Mov ebx,PCR[KPCR_CURRENT_THREAD] //ebx=KTHREAD*（当前线程对象的地址）
Mov byte ptr[ebx+KTHREAD_ALERTED],0 //kthread.Alert修改为不可提醒
Cmp byte ptr[ebx+KTHREAD_PENDING_USER_APC],0
Je 2 //如果当前线程的用户apc队列为空，直接跳过
Mov ebx,ebp //ebx=TrapFrame帧的地址
Mov [ebx,KTRAP_FRAME_EAX],eax //保存
Mov ecx,APC_LEVEL
Call KfRaiseIrql //call KfRaiseIrql(APC_LEVEL)
Push eax //保存提升irql之前的irql
Sti
Push ebx //TrapFrame帧的地址
Push NULL
Push UserMode
Call KiDeliverApc //call KiDeliverApc(UserMode, NULL, TrapFrame*)
Pop ecx // ecx=之前的irql
Call KfLowerIrql //call KfLowerIrql(之前的irql)
Move eax, [ebx,KTRAP_FRAME_EAX] //恢复eax
Cli
Jmp 1 //再次跳回1处循环，扫描apc队列
…
关键的函数是KiDeliverApc，这个函数用来真正扫描apc队列执行所有apc，我们看：
VOID
KiDeliverApc(IN KPROCESSOR_MODE DeliveryMode,//指要执行哪个apc队列中的函数
IN PKEXCEPTION_FRAME ExceptionFrame,//传入的是NULL
IN PKTRAP_FRAME TrapFrame)//即将返回用户空间前的Trap现场帧
{
PKTHREAD Thread = KeGetCurrentThread();
PKPROCESS Process = Thread->ApcState.Process;
OldTrapFrame = Thread->TrapFrame;
Thread->TrapFrame = TrapFrame;
Thread->ApcState.KernelApcPending = FALSE;
if (Thread->SpecialApcDisable) goto Quickie;
//先固定执行掉内核apc队列中的所有apc函数
while (!IsListEmpty(&Thread->ApcState.ApcListHead[KernelMode]))
{
KiAcquireApcLockAtApcLevel(Thread, &ApcLock);//锁定apc队列
ApcListEntry = Thread->ApcState.ApcListHead[KernelMode].Flink;//队列头部中的apc
Apc = CONTAINING_RECORD(ApcListEntry, KAPC, ApcListEntry);
KernelRoutine = Apc->KernelRoutine;//内核总apc函数
NormalRoutine = Apc->NormalRoutine;//用户自己真正的内核apc函数
NormalContext = Apc->NormalContext;//真正内核apc函数的context*
SystemArgument1 = Apc->SystemArgument1;
SystemArgument2 = Apc->SystemArgument2;
if (NormalRoutine==NULL) //称为Special Apc,少见
{
RemoveEntryList(ApcListEntry);//关键，移除队列
Apc->Inserted = FALSE;
KiReleaseApcLock(&ApcLock);
//执行内核中的总apc函数
KernelRoutine(Apc,&NormalRoutine,&NormalContext,
&SystemArgument1,&SystemArgument2);
}
Else //典型，一般程序员都会提供一个自己的内核apc函数
{
if ((Thread->ApcState.KernelApcInProgress) || (Thread->KernelApcDisable))
{
KiReleaseApcLock(&ApcLock);
goto Quickie;
}
RemoveEntryList(ApcListEntry); //关键，移除队列
Apc->Inserted = FALSE;
KiReleaseApcLock(&ApcLock);
//执行内核中的总apc函数
KernelRoutine(Apc,
&NormalRoutine,//注意，内核中的总apc可能会在内部修改NormalRoutine
&NormalContext,
&SystemArgument1,
&SystemArgument2);
if (NormalRoutine)//如果内核总apc没有修改NormalRoutine成NULL
{
Thread->ApcState.KernelApcInProgress = TRUE;//标记当前线程正在执行内核apc
KeLowerIrql(PASSIVE_LEVEL);
//直接调用用户提供的真正内核apc函数
NormalRoutine(NormalContext, SystemArgument1, SystemArgument2);
KeRaiseIrql(APC_LEVEL, &ApcLock.OldIrql);
}
Thread->ApcState.KernelApcInProgress = FALSE;
}
}
//上面的循环，执行掉所有内核apc函数后，下面开始执行用户apc队列中的第一个apc
if ((DeliveryMode == UserMode) &&
!(IsListEmpty(&Thread->ApcState.ApcListHead[UserMode])) &&
(Thread->ApcState.UserApcPending))
{
KiAcquireApcLockAtApcLevel(Thread, &ApcLock);//锁定apc队列
Thread->ApcState.UserApcPending = FALSE;
ApcListEntry = Thread->ApcState.ApcListHead[UserMode].Flink;//队列头
Apc = CONTAINING_RECORD(ApcListEntry, KAPC, ApcListEntry);
KernelRoutine = Apc->KernelRoutine; //内核总apc函数
NormalRoutine = Apc->NormalRoutine; //用户空间的总apc函数
NormalContext = Apc->NormalContext;//用户真正的用户空间apc函数
SystemArgument1 = Apc->SystemArgument1;//真正apc的context*
SystemArgument2 = Apc->SystemArgument2;
RemoveEntryList(ApcListEntry);//关键，移除队列
Apc->Inserted = FALSE;
KiReleaseApcLock(&ApcLock);
KernelRoutine(Apc,
&NormalRoutine,// 注意，内核中的总apc可能会在内部修改NormalRoutine
&NormalContext,
&SystemArgument1,
&SystemArgument2);
if (!NormalRoutine)
KeTestAlertThread(UserMode);
Else //典型，准备提前回到用户空间调用用户空间的总apc函数
{
KiInitializeUserApc(ExceptionFrame,//NULL
TrapFrame,//Trap帧的地址
NormalRoutine, //用户空间的总apc函数
NormalContext, //用户真正的用户空间apc函数
SystemArgument1, //真正apc的context*
SystemArgument2);
}
}
Quickie:
Thread->TrapFrame = OldTrapFrame;
}
如上，这个函数既可以用来投递处理内核apc函数，也可以用来投递处理用户apc队列中的函数。
特别的，当要调用这个函数投递处理用户apc队列中的函数时，它每次只处理一个用户apc。
由于正式回到用户空间前，会循环调用这个函数。因此，实际的处理顺序是：
扫描执行内核apc队列所有apc->执行用户apc队列中一个apc->再次扫描执行内核apc队列所有apc->执行用户apc队列中下一个apc->再次扫描执行内核apc队列所有apc->再次执行用户apc队列中下一个apc如此循环，直到将用户apc队列中的所有apc都执行掉。
执行用户apc队列中的apc函数与内核apc不同，因为用户apc队列中的apc函数自然是要在用户空间中执行的，而KiDeliverApc这个函数本身位于内核空间，因此，不能直接调用用户apc函数，需要‘提前’回到用户空间去执行队列中的每个用户apc，然后重新返回内核，再次扫描整个内核apc队列，再执行用户apc队列中遗留的下一个用户apc。如此循环，直至执行完所有用户apc后，才‘正式’返回用户空间。
下面的函数就是用来为执行用户apc做准备的。
VOID
KiInitializeUserApc(IN PKEXCEPTION_FRAME ExceptionFrame,
IN PKTRAP_FRAME TrapFrame,//原真正的断点现场帧
IN PKNORMAL_ROUTINE NormalRoutine,
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2)
{
Context.ContextFlags = CONTEXT_FULL | CONTEXT_DEBUG_REGISTERS;
//将原真正的Trap帧打包保存在一个Context结构中
KeTrapFrameToContext(TrapFrame, ExceptionFrame, &Context);
_SEH2_TRY
{
AlignedEsp = Context.Esp & ~3;//对齐4B
//为用户空间中KiUserApcDisatcher函数的参数腾出空间（4个参数+ CONTEXT + 8B的seh节点）
ContextLength = CONTEXT_ALIGNED_SIZE + (4 * sizeof(ULONG_PTR));
Stack = ((AlignedEsp - 8) & ~3) - ContextLength;//8表示seh节点的大小
//模拟压入KiUserApcDispatcher函数的4个参数
*(PULONG_PTR)(Stack + 0 * sizeof(ULONG_PTR)) = (ULONG_PTR)NormalRoutine;
*(PULONG_PTR)(Stack + 1 * sizeof(ULONG_PTR)) = (ULONG_PTR)NormalContext;
*(PULONG_PTR)(Stack + 2 * sizeof(ULONG_PTR)) = (ULONG_PTR)SystemArgument1;
*(PULONG_PTR)(Stack + 3 * sizeof(ULONG_PTR)) = (ULONG_PTR)SystemArgument2;
//将原真正trap帧保存在用户栈的一个CONTEXT结构中，方便以后还原
RtlCopyMemory( (Stack + (4 * sizeof(ULONG_PTR))),&Context,sizeof(CONTEXT));
//强制修改当前Trap帧中的返回地址与用户栈地址（偏离原来的返回路线）
TrapFrame->Eip = (ULONG)KeUserApcDispatcher;//关键，新的返回断点地址
TrapFrame->HardwareEsp = Stack;//关键，新的用户栈顶
TrapFrame->SegCs = Ke386SanitizeSeg(KGDT_R3_CODE, UserMode);
TrapFrame->HardwareSegSs = Ke386SanitizeSeg(KGDT_R3_DATA, UserMode);
TrapFrame->SegDs = Ke386SanitizeSeg(KGDT_R3_DATA, UserMode);
TrapFrame->SegEs = Ke386SanitizeSeg(KGDT_R3_DATA, UserMode);
TrapFrame->SegFs = Ke386SanitizeSeg(KGDT_R3_TEB, UserMode);
TrapFrame->SegGs = 0;
TrapFrame->ErrCode = 0;
TrapFrame->EFlags = Ke386SanitizeFlags(Context.EFlags, UserMode);
if (KeGetCurrentThread()->Iopl) TrapFrame->EFlags |= EFLAGS_IOPL;
}
_SEH2_EXCEPT((RtlCopyMemory(&SehExceptRecord, _SEH2_GetExceptionInformation()->ExceptionRecord, sizeof(EXCEPTION_RECORD)), EXCEPTION_EXECUTE_HANDLER))
{
SehExceptRecord.ExceptionAddress = (PVOID)TrapFrame->Eip;
KiDispatchException(&SehExceptRecord,ExceptionFrame,TrapFrame,UserMode,TRUE);
}
_SEH2_END;
}
至于为什么要放在一个try块中保护，是因为用户空间中的栈地址，谁也无法保证会不会出现崩溃。
如上，这个函数修改返回地址，回到用户空间中的KiUserApcDisatcher函数处去。然后把原trap帧保存在用户栈中。由于KiUserApcDisatcher这个函数有参数，所以需要模拟压入这个函数的参数，这样，当返回到用户空间时，就仿佛是在调用这个函数。看下那个函数的代码：
KiUserApcDisatcher(NormalRoutine,
NormalContext,
SysArg1,
SysArg2
)
{
Lea eax,[esp+ CONTEXT_ALIGNED_SIZE+16] //eax指向seh异常节点的地址
Mov ecx,fs:[TEB_EXCEPTION_LIST]
Mov edx,offset KiUserApcExceptionHandler
--------------------------------------------------------------------------------------
Mov [eax],ecx //seh节点的next指针成员
Mov [eax+4],edx //she节点的handler函数指针成员
Mov fs:[TEB_EXCEPTION_LIST],eax
--------------------上面三条指令在栈中构造一个8B的标准seh节点-----------------------
Pop eax //eax=NormalRoutine（即IntCallUserApc这个总apc函数）
Lea edi,[esp+12] //edi=栈中保存的CONTEXT结构的地址
Call eax //相当于call IntCallUserApc（NormalContext，SysArg1，SysArg2）
Mov ecx,[edi+ CONTEXT_ALIGNED_SIZE]
Mov fs:[ TEB_EXCEPTION_LIST],ecx //撤销栈中的seh节点
Push TRUE //表示回到内核后需要继续检测执行用户apc队列中的apc函数
Push edi //传入原栈帧的CONTEXT结构的地址给这个函数，以做恢复工作
Call NtContinue //调用这个函数重新进入内核（注意这个函数正常情况下是不会返回到下面的）
----------------------------------华丽的分割线-------------------------------------------
Mov esi,eax
Push esi
Call RtlRaiseStatus //若ZwContinue返回了，那一定是内部出现了异常
Jmp StatusRaiseApc
Ret 16
}
如上，每当要执行一个用户空间apc时，都会‘提前’偏离原来的路线返回用户空间的这个函数处去执行用户的apc。在执行这个函数前，会先构造一个seh节点，也即相当于把这个函数的调用放在try块中保护。这个函数内部会调用IntCallUserApc，执行完真正的用户apc函数后，调用ZwContinue重返内核。
Void CALLBACK //用户空间的总apc函数
IntCallUserApc(void* RealApcFunc, void* SysArg1,void* SysArg2)
{
(*RealApcFunc)(SysArg1);//也即调用RealApcFunc（void* context）
}
NTSTATUS NtContinue(CONTEXT* Context, //原真正的TraFrame
BOOL TestAlert //指示是否继续执行用户apc队列中的apc函数
)
{
Push ebp //此时ebp=本系统服务自身的TrapFrame地址
Mov ebx,PCR[KPCR_CURRENT_THREAD] //ebx=当前线程的KTHREAD对象地址
Mov edx,[ebp+KTRAP_FRAME_EDX] //注意TrapFrame中的这个edx字段不是用来保存edx的
Mov [ebx+KTHREAD_TRAP_FRAME],edx //将当前的TrapFrame改为上一个TrapFrame的地址
Mov ebp,esp
Mob eax,[ebp] //eax=本系统服务自身的TrapFrame地址
Mov ecx,[ebp+8] /本函数的第一个参数，即Context
Push eax
Push NULL
Push ecx
Call KiContinue //call KiContinue(Context*,NULL,TrapFrame*)
Or eax,eax
Jnz error
Cmp dword ptr[ebp+12],0 //检查TestAlert参数的值
Je DontTest
Mov al,[ebx+KTHREAD_PREVIOUS_MODE]
Push eax
Call KeTestAlertThread //检测用户apc队列是否为空
DontTest：
Pop ebp
Mov esp,ebp
Jmp KiServiceExit2 //返回用户空间（返回前，又会去扫描执行apc队列中的下一个用户apc）
}
NTSTATUS
KiContinue(IN PCONTEXT Context,//原来的断点现场
IN PKEXCEPTION_FRAME ExceptionFrame,
IN PKTRAP_FRAME TrapFrame) //NtContinue自身的TrapFrame地址
{
NTSTATUS Status = STATUS_SUCCESS;
KIRQL OldIrql = APC_LEVEL;
KPROCESSOR_MODE PreviousMode = KeGetPreviousMode();
if (KeGetCurrentIrql() < APC_LEVEL)
KeRaiseIrql(APC_LEVEL, &OldIrql);
_SEH2_TRY
{
if (PreviousMode != KernelMode)
KiContinuePreviousModeUser(Context,ExceptionFrame,TrapFrame);//恢复成原TrapFrame
else
{
KeContextToTrapFrame(Context,ExceptionFrame,TrapFrame,Context->ContextFlags,
KernelMode); //恢复成原TrapFrame
}
}
_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
{
Status = _SEH2_GetExceptionCode();
}
_SEH2_END;
if (OldIrql < APC_LEVEL)
KeLowerIrql(OldIrql);
return Status;
}
VOID
KiContinuePreviousModeUser(IN PCONTEXT Context,//原来的断点现场
IN PKEXCEPTION_FRAME ExceptionFrame,
IN PKTRAP_FRAME TrapFrame)//NtContinue自身的TrapFrame地址
{
CONTEXT LocalContext;
ProbeForRead(Context, sizeof(CONTEXT), sizeof(ULONG));
RtlCopyMemory(&LocalContext, Context, sizeof(CONTEXT));
Context = &LocalContext;
//看到没，将原Context中的成员填写到NtContinue系统服务的TrapFrame帧中（也即修改成原来的TrapFrame）
KeContextToTrapFrame(&LocalContext,ExceptionFrame,TrapFrame,
LocalContext.ContextFlags,UserMode);
}
如上，上面的函数，就把NtContinue的TrapFrame强制还原成原来的TrapFrame，以好‘正式’返回到用户空间的真正断点处（不过在返回用户空间前，又要去扫描用户apc队列，若仍有用户apc函数，就先执行掉内核apc队列中的所有apc函数，然后又偏离原来的返回路线，‘提前’返回到用户空间的KiUserApcDispatcher函数去执行用户apc，这是一个不断循环的过程。可见，NtContinue这个函数不仅含有继续回到原真正用户空间断点处的意思，还含有继续执行用户apc队列中下一个apc函数的意思）
BOOLEAN KeTestAlertThread(IN KPROCESSOR_MODE AlertMode)
{
PKTHREAD Thread = KeGetCurrentThread();
KiAcquireApcLock(Thread, &ApcLock);
OldState = Thread->Alerted[AlertMode];
if (OldState)
Thread->Alerted[AlertMode] = FALSE;
else if ((AlertMode != KernelMode) &&
(!IsListEmpty(&Thread->ApcState.ApcListHead[UserMode])))
{
Thread->ApcState.UserApcPending = TRUE;//关键。又标记为不空，从而又去执行用户apc
}
KiReleaseApcLock(&ApcLock);
return OldState;
}
上面这个函数的关键工作是检测到用户apc队列不为空，就又将UserApcPending标志置于TRUE。
前面我们看到的是用户apc队列的执行机制与时机，那是用户apc唯一的执行时机。内核apc队列中的apc执行时机是不相同的，而且有很多执行时机。
内核apc的执行时机主要有：
1、 每次返回用户空间前，每执行一个用户apc前，就会扫描执行整个内核apc队列
2、 每当调用KeLowerIrql,从APC_LEVEL以上（不包括APC_LEVEL） 降到 APC_LEVEL以下（不包括APC_LEVEL）前，中途会检查是否有阻塞的apc中断请求，若有就扫描执行内核apc队列
3、 每当线程重新得到调度，开始运行前，会扫描执行内核apc队列 或者 发出apc中断请求
内核apc的执行时机：【调度、返、降】apc
KeLowerIrql实质上是下面的函数：
VOID FASTCALL
KfLowerIrql(IN KIRQL OldIrql)
{
ULONG EFlags;
ULONG PendingIrql, PendingIrqlMask;
PKPCR Pcr = KeGetPcr();
PIC_MASK Mask;
EFlags = __readeflags();//保存原eflags
_disable();//关中断
Pcr->Irql = OldIrql;//降到目标irql
//检测是否有高于目标irql的阻塞中的软中断
PendingIrqlMask = Pcr->IRR & FindHigherIrqlMask[OldIrql];
if (PendingIrqlMask)//若有
{
BitScanReverse(&PendingIrql, PendingIrqlMask);//找到最高级别的软中断
if (PendingIrql > DISPATCH_LEVEL)
{
Mask.Both = Pcr->IDR;
__outbyte(PIC1_DATA_PORT, Mask.Master);
__outbyte(PIC2_DATA_PORT, Mask.Slave);
Pcr->IRR ^= (1 << PendingIrql);
}
SWInterruptHandlerTable[PendingIrql]();//处理阻塞的软中断（即扫描执行队列中的函数）
}
__writeeflags(EFlags);//恢复原eflags
}
这个函数在从当前irql降到目标irql时，会按irql高低顺序执行各个软中断的isr。
软中断是用来模拟硬件中断的一种中断。
#define PASSIVE_LEVEL 0
#define APC_LEVEL 1
#define DISPATCH_LEVEL 2
#define CMCI_LEVEL 5
比如，当调用KfLowerIrql要将cpu的irql从CMCI_LEVEL降低到PASSIVE_LEVEL时，这个函数中途会先看看当前cpu是否收到了CMCI_LEVEL级的软中断，若有，就调用那个软中断的isr处理之。然后，再检查是否收到有DISPATCH_LEVEL级的软中断，若有，调用那个软中断的isr处理之，然后，检查是否有APC中断，若有，同样处理之。最后，降到目标irql，即PASSIVE_LEVEL。
换句话说，在irql的降低过程中会一路检查、处理中途的软中断。Cpu数据结构中有一个IRR字段，即表示当前cpu累积收到了哪些级别的软中断。
下面的函数可用于模拟硬件，向cpu发出任意irql级别的软中断，请求cpu处理执行那种中断。
VOID FASTCALL
HalRequestSoftwareInterrupt(IN KIRQL Irql)//Irql一般是APC_LEVEL/DPC_LEVEL
{
ULONG EFlags;
PKPCR Pcr = KeGetPcr();
KIRQL PendingIrql;
EFlags = __readeflags();//保存老的eflags寄存器
_disable();//关中断
Pcr->IRR |= (1 << Irql);//关键。标志向cpu发出了一个对应irql级的软中断
PendingIrql = SWInterruptLookUpTable[Pcr->IRR & 3];//IRR后两位表示是否有阻塞的apc中断
//若有阻塞的apc中断，并且当前irql是PASSIVE_LEVEL,立即执行apc。也即在PASSIVE_LEVEL级时发出任意软中断后，会立即检查执行现有的apc中断。
if (PendingIrql > Pcr->Irql)
SWInterruptHandlerTable[PendingIrql]();//调用执行apc中断的isr，处理apc中断
__writeeflags(EFlags);//恢复原eflags寄存器
}
那么什么时候，系统会调用这个函数，向cpu发出apc中断呢？
典型的情形1：
在切换线程时，若将线程的WaitIrql置为APC_LEVEL,将导致KiSwapContextInternal函数内部在重新切回来后，立即自动发出一个apc中断，以在下次降低irql到PASSIVE_LEVEL时处理执行队列中那些阻塞的apc。反之，若将线程的WaitIrql置为PASSIVE_LEVEL,将导致KiSwapContextInternal函数内部在重新切回来后，不会发出apc中断，然后系统会自行显式调用KiDeliverApc给予扫描执行
典型情形2：
在给自身线程发送一个内核apc时，在apc进队的同时，会发出apc中断，以请求cpu在下次降低irql时，扫描执行apc。
Apc是一种软中断，既然是中断，他也有类似的isr。Apc中断的isr最终进入 HalpApcInterruptHandler
VOID FASTCALL
HalpApcInterruptHandler(IN PKTRAP_FRAME TrapFrame)
{
//模拟硬件中断压入保存的寄存器
TrapFrame->EFlags = __readeflags();
TrapFrame->SegCs = KGDT_R0_CODE;
TrapFrame->Eip = TrapFrame->Eax;
KiEnterInterruptTrap(TrapFrame);//构造Trap现场帧
扫描执行当前线程的内核apc队列，略…
KiEoiHelper(TrapFrame);
}
