当前位置: 首页>后端>正文

chibios的优先级越大 硬件优先级

 

1.1 管理硬件优先级
特定设备或中间层驱动程序例程运行的IRQL决定了它能调用哪些内核模式的支持例程。例如,有些支持例程要求调用者运行在为DISPATCH_LEVEL的IRQL上。其他例程在调用者运行在提高的(raised)IRQL(即高于PASSIVE_LEVEL的IRQL)时不能被安全地调用。

表16.1列出了最常见的标准驱动程序例程被调用的缺省IRQL以及Kernel定义的IRQL值(由低到高)。

表16.1 驱动程序例程的缺省IRQL

IRQL(由低到高)
屏蔽掉的中断
运行在此IRQL的支持例程

PASSIVE_LEVEL

Dispatch、DriverEntry、AddDevice、Reinitialize、Unload例程、驱动程序创建的线程、工作者线程(work-thread)回调、文件系统驱动程序



DISPATCH_LEVEL
DISPATCH_LEVEL和APC_LEVEL中断被屏蔽掉了。设备、时钟和电源错误中断仍可发生
StartIo、AdapterControl、AdapterListControl、ControllerControl、IoTimer、Cancel(持有撤消自旋锁时)、DpcForIsr、CustomTimerDpc、CustomDpc例程



DIRQL
驱动程序中断对象中所有IRQL<=DIRQL的中断。时钟和电源错误中断仍可发生
ISR、SyncCritSection例程


当运行在下列三种IRQL之一时,由最低层驱动程序处理IRP:

§    PASSIVE_LEVEL:没有处理器中断被屏蔽掉,在驱动程序的Dispatch例程中。

DriverEntry、AddDevice、Reinitialize和Unload例程也运行在PASSIVE_LEVEL,此外还有驱动程序创建的系统线程

§    DISPATCH_LEVEL:处理器的DISPATCH_LEVEL和APC_LEVEL中断被屏蔽掉了,在StartIo例程中。

AdapterControl、AdapterListControl、ControllerControl、IoTimer、Cancel(持有撤消自旋锁时)、DpcForIsr、CustomTimerDpc和CustomDpc例程也都运行在DISPATCH_LEVEL。

§    Device IRQL(DIRQL):处理器上所有低于或等于驱动程序中断对象的SynchronizeIrql的中断都被屏蔽掉了,在ISR和SyncCritSection例程中。

当运行在下列两种IRQL时,由更高层驱动程序处理IRP:

§    PASSIVE_LEVEL:没有处理器中断被屏蔽掉,在驱动程序的Dispatch例程中。

DriverEntry、AddDevice、Reinitialize和Unload例程也运行在PASSIVE_LEVEL,此外还有驱动程序创建的系统线程、工作者线程回调或文件系统驱动程序。

§    DISPATCH_LEVEL:处理器的DISPATCH_LEVEL和APC_LEVEL中断被屏蔽掉了,在驱动程序的IoCompletion例程中。

IoTimer、Cancel和CustomTimerDpc例程也都运行在DISPATCH_LEVEL。

有时,海量存储设备的中间层和最低层驱动程序在等于APC_LEVEL的IRQL上被调用。特别是,这种情况会在文件系统驱动程序向低层驱动程序发送IRP_MJ_READ请求导致页错误时发生。

大多数标准驱动程序例程运行在仅能使它们调用适当的支持例程的IRQL上。例如,当设备驱动程序运行在等于DISPATCH_LEVEL的IRQL上时,它必须调用AllocateAdapter或IoAllocateController。由于多数设备驱动程序从StartIo例程中调用这些例程,因此它们通常运行在DISPATCH_LEVEL。

应注意的是,对于没有StartIo例程的设备驱动程序,因为它建立并管理自己的IRP队列,所以当它应该调用AllocateAdapter(或IoAllocateController)时,不一定非要运行在等于DISPATCH_LEVEL的IRQL上。这样的驱动程序必须在调用KeRaiseIrql和调用KeLowerIrql之间调用AllocateAdapter,于是当它调用AllocateAdapter时,就能运行在要求的IRQL上,而且当调用例程重新获得控制时,能够恢复初始IRQL。

为了能在适当的IRQL调用支持例程并能在驱动程序中成功地管理硬件优先级,应当注意下列情况:

§    用低于当前IRQL的输入NewIrql值调用KeRaiseIrql会导致一个致命错误。调用KeLowerIrql以期望恢复初始IRQL(也就是,在调用KeRaiseIrql之后)也会导致一个致命错误。

§    当运行在提高的IRQL上时,用Kernel定义的调度者对象调用KeWaitForSingleObject或KeWaitForMultipleObjects以在非零时间段中等待会导致一个致命错误。只有运行在非任意线程和PASSIVE_LEVEL的驱动程序例程(如驱动程序创建的线程、DriverEntry例程和Reinitialize例程、或像大多数设备I/O控制请求那样的同步I/O操作的Dispatch例程)能在非零时间段中安全地等待时间、信号量、互斥体或定时器。

§    即使运行在PASSIVE_LEVEL上,可分页代码也决不能在输入Wait参数为TRUE的情况下,用它调用KeSetEvent、KeReleaseSemaphore或KeReleaseMutex。这样的调用会导致一个致命的页错误。

§    运行在高于APC_LEVEL的IRQL上的例程既不能从页式存储池中分配内存,也不能安全地访问页式存储池中的内存。如果这样的例程引起了一个页错误,这个错误将是致命的。

§    当驱动程序调用KeAcquireSpinLockAtDpcLevel和KeRelaeseSpinLockFromDpcLevel时,它必须运行在DISPATCH_LEVEL上。

当驱动程序调用KeAcquireSpinLock时,它可以运行在低于DISPATCH_LEVEL的IRQL上,但是它必须通过调用KeRelaeseSpinLock释放这个自旋锁。也就是说,通过调用KeRelaeseSpinLockFromDpcLevel释放由调用KeAcquireSpinLock获得的自旋锁是编程错误。

当驱动程序运行在高于DISPATCH_LEVEL的IRQL上时,它绝对不能调用KeAcquireSpinLockAtDpcLevel、KeRelaeseSpinLockFromDpcLevel、KeAcquireSpinLock或KeRelaeseSpinLock。

§    如果调用者还没有运行在这些提高后的IRQL上,调用使用了自旋锁的支持例程(如ExInterlockedXxx)会将当前处理器上的IRQL提高到DISPATCH_LEVEL或DIRQL。

§    运行在提高IRQL上的驱动程序代码应该尽快执行。为了获得好的整体性能,例程运行的IRQL越高,就越应该将例程执行速度调得尽可能快。例如,调用KeRaiseIrql的驱动程序应当尽快地做逆调用KeLowerIrql。

请使用在线DDK参见“使用自旋锁”部分和例程相应的参考部分。

exallocatepool(); 
exinitializeworkitem(); 
exqueueworkitem();


内核驱动与文件创建读写
目的:
在内核驱动中创建文件,并进行读写。用于保存驱动运行中的信息。

方式:
可以用两种方式实现该操作。
1、 在应用程序中创建文件,驱动运用IOCTL将信息传给应用层,应用程序对文件进行读写。Tdi_fw就是利用这种方式来记录驱动过滤信息,Tdi_fw的应用程序创建一个线程,循环利用IOCTL来读取驱动信息,并保存到文件。
2、 在驱动中完成所有的这些操作。在这里我们主要讨论这种方式。

实现:
利用ZwCreateFile创建磁盘文件,利用ZwReadFile、ZwWriteFile读写文件。
创建文件代码如下:

RtlInitUnicodeString (&usname,L"//SystemRoot//System32//LogFiles//passthru.log"); 
InitializeObjectAttributes(&oa, &usname, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);
Status = ZwCreateFile(&hfile, GENERIC_WRITE, &oa, &iostatus, NULL,
   FILE_ATTRIBUTE_NORMAL,FILE_SHARE_READ, FILE_OVERWRITE_IF, FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0);



写文件的代码如下:
ZwWriteFile(hfile, NULL, NULL, NULL, &iostatus, PrintContent, count, NULL, NULL);

这些代码倒是不难,网上找一些例子就搞定了。
注意两点:
1、 记得要在结束时,ZwClose(hFile)。
2、 系统刚启动时,最好将文件创建于C:,或者系统文件下。否则会创建文件失败。
真正的问题在下面,这些Zw函数都只能运行在PASSIVE_LEVEL上。在DISPATCH_LEVEL上调用这几个函数会出现BSOD。这时问题就来了,我们在PtReceive函数里面也需要保存一些运行的信息,而PtReceive处于DISPATCH_LEVEL的级别。这个问题需要解决。

这里有两种方式:
1.运用工作队列WorkItem,WorkItem能排队注册的回调函数。当例程处于DISPATCH_LEVEL级别时将回调函数塞入队列,当进程降低到PASSIVE_LEVEL时,这些队列中的回调函数将会被系统调用。
2.运用PsCreateSystemThread方式注册一个线程,在注册一个事件,申请一段内存。
在我们有信息写入文件的时候,先将信息写入内存,然后Set这个事件。在这个线程中循环KeWaitForSingleObject这个Event。然后在调用ZwWriteFile将信息写入文件。这里要注意一点的是文件读写的同步问题。我实现的就是这种方案。




4月20日补充:
1、可以用用RtlStringCbPrintfA代替sprintf函数,对内存进行字符串初始化。例子如下:

#include "ntstrsafe.h"

CHAR pszDest[30];
ULONG cbDest = 30;
LPCSTR pszFormat = "%s %d + %d = %d.";
CHAR* pszTxt = "The answer is";

RtlStringCbPrintfA(pszDest, cbDest, pszFormat, pszTxt, 1, 2, 3);
KdPrint(("%s",pszDest));


需要注意的是这个函数还有另一个版本RtlStringCbPrintfW,专门用来对UNICODE进行超作。其他可能对我们比较有用的函数是RtlStringCbCopyA和RtlStringCbCatA用于拷贝和连接。操作都很简单,它们本身就是驱动下的sprintf的替代版本。

2、发现一个问题,就是安装完驱动重启后,在DriverEntry调用那个ZwCreateFile函数会返回失败。而在系统启动以后安装Passthru,就不会出现这个问题。原因是在操作系统启动时,系统初始化Passthru,调用我们的DriverEntry函数。这时候磁盘还没完全初始化好无法访问磁盘。
这个问题其实对我们来说没有什么影响,我们需要记录信息的时候,一定是在应用程序客户端已经开启后的事情了。这时候磁盘早已启动好了,我们不用担心。
这里的解决方法是,在应用程序一启动,打开驱动设备的时候,才ZwCreateFile。这样一定是可以的。

3、 运用WorkItem进行系统回调函数排队的方法也不难。在NDIS下可以使用NdisInitializeWorkItem和NdisScheduleWorkItem函数来排队我们在高irql下的不能执行的动作。等到进程下降到passive_level时,这些已经排队了的回调函数就会Dequeue。
这个方法我今天试过了,可以使用。但是从效率来讲,并没有什么突出的地方。而且根据CSDN的介绍,工作队列有两个需要注意的地方。一是不能执行太长的操作,会死锁。2是在排队工作项之前,最好释放所有的mutex、lock、semaphore,否则很容易死锁。反正这两种操作都不错(另一种线程的方法参见前面文档)。随便选一个用用就行了。

Regmon(2)


if(NT_SUCCESS(ntStatus))
{


创建符号连接,以便GUI能够指名,访问这个驱动/设备
创建每个需要处理的方法的分发点

DriverObject->MajorFunction[IRP_MJ_SHUTDOWN] = 
DriverObject->MajorFunction[IRP_MJ_CREATE] = 
DriverObject->MajorFunction[IRP_MJ_CLOSE] =
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = RegmonDispatch;
#if DBG
DriverObject->DriverUnload = RegmonUnload;
#end if
}

if(!NT_SUCCESS(ntStatus))
{
DbgPrint((“Regmon: Failed   to create our device!/n”));


发生错误,清理环境(资源等)

if(GUIDevice) IoDeleteDevice(GUIDevice);
IoDeleteSymbolicLink(&deviceLinkUnicodeString);
return ntStatus;
}



初始化互斥量

MUTEX_INIT(StoreMutex);
MUTEX_INIT(HashMutex);
MUTEX_INIT(FilterMutex);



初始化根键长度

for(I = 0; I < NUMROOTKEYS; I ++)
{
RootKey[I].RootNameLen = strlen(RootKey[I].RootName;
}
for(I = 0; I < 2; I ++)
{
CurrentUser[I].RootNameLen = strlen(CurrentUser[I].RootName;
}



系统表数据结构指针,一个NTOSKRNL导出
ServiceTable = KeServiceDescriptorTable; 用户自定义的结构

DbgPrint((“HookRegistry:Servicetable:%x/n”, ServiceTable));


获取进程名称的偏移
ProcessNameOffset = GetProcessNameOffset(); 这个函数是牛人自己写的。

分配初始化的输出缓冲区

Store = ExAllocatePool(PagePool, sizeof(*Store));
if(!Store)
{
IoDeleteDevice(GUIDevice);
IoDeleteSymbolicLink(&deviceLinkUnicodeString);
return STATUS_INSUFFICENT_RESOURCES;
}
Store->Len = 0;
Store->Next = NULL;
NumStore = 1;



如果我们是个启动设备则开始记日志

if(startType != SERVICE_DEMAND_START)
{


初始化日志

BoolLogging = TRUE;

KeInitializeEvent(&LoggingEvent, SynchronizationEvent, FALSE);
GUIActive = TRUE;
Fileltet = BootFilter;
RegmonUpdateFilters();
HookRegisters();



告诉用户,日志模式已经开启

RtlInitUnicodeString(&bootMessageUnicodeString, bootMessage);
ZwDisplayString(&bootMessageUnicodeString);



注册关闭通知
IoRegisterShutdonwNotification注册一个驱动提供的系统关闭通知函数,在系统被完全关闭之前调用。

IoRegisterShutdown Notification(GUIDevice);

}
return STATUS_SUCCESS;
}









RegmonDispatch
这个函数处理设备的请求。需要显示处理的请求来自GUI。当然,当GUI建立,关闭合驱动的通信时,也需要处理Create,Close。

NTSTAUTS RegmonDispatch(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
PIO_STACK_LOCATION irpStack; 当前堆栈
PVOID inputBuffer;
PVOID outputBuffer;
ULONG inputBufferLength;
ULONG outputBufferLength;
ULONG ioControlCode;
PSTORE_BUF old;
WORK_QUEUE_ITEM workItem;



设置处理成功

Irp->IoStatus.Status = STATUS_SUCCESS;
Irp->IoStatus.Information = 0;



获取Irp中当前位置的指针,这就是代码和参数定位的地方

irpStack = IoGetCurrentIrpStackLocation(Irp);

inputBuffer = Irp->AssociatedIrp.SystemBuffer;
inputBufferLength = iprStack->Parameters.DeviceIoControl.InputBufferLength;
outputBuffer = Irp->AssociatedIrp.SystemBuffer;
outputBufferLength = irpStack->Parameters.DeviceIoControl.OutputBufferLength;
ioControlCode = irpStack->Parameters.DeviceIoControl.IoControlCode;

switch(irpStack->MajorFunction)
{
case IRP_MJ_CREATE:
       DbgPrint((“Regmon: IRP_MJ_CREATE/n”));
       关闭启动日志
       if(BootLogging)
       {
         BootLogging = FALSE;
         IoUnregisterShutdownNotification(DeviceObject);
         MUTEX_WAIT(StoreMutex);
         ExInitializeWorkItem(&workItem, RegmonCloseBootLog, 0);


这个函数已经过期,应该使用IoAllocateWorkItem。返回一个指向私有结构IO_WORKITEM的指针。驱动不应该以任何形式访问这个结构!
         ExQueueWorkItem(&workItem, CriticalWorkQueue);
         这个函数也过期了,应该使用IoQueueWorkItem。插入一个指定的工作项到队列中,这个队列由系统工作线程访问,系统工作线程从队列中移出一个工作项,并调用其中的回调函数。

KeWaitForSingleObject(&LoggingEvent, Executive, KernelMode, FALSE, NULL);
         MUTEX_RELEASE(StoreMutex);
       }
       Sequence = 0;
       GUIActive = TRUE;
       DbgPrint((“GUI Active: %d/n”, GUIActive));
       break;
}
}



还能继续小
Project->Settings打开Link属性页,将Object/library modules:下面编辑框中的各种lib全部删除,然后打上msvcrt.lib kernel32.lib user32.lib
Project->Settings的Link属性页里,在Project Options下面的编辑框里加上一句:/ALIGN:4096

这都是些简洁的方法


https://www.xamrdz.com/backend/35y1960930.html

相关文章: