Hey guys, Im new kernel driver developer.
I want to install callout and filters when my driver receives IO request from user-mode application.
But the document says EVT_WDF_IO_QUEUE_IO_DEVICE_CONTROL (EvtIoDeviceControl) run at <= DISPATCH_LEVEL,
and the most WFP functions run at PASSIVE_LEVEL.
Is âset WdfExecutionLevelPassive to the ExecutionLevel member of the device or driverâs WDF_OBJECT_ATTRIBUTES structureâ a good practice ? Or others way ?
Is âset WdfExecutionLevelPassive to the ExecutionLevel member of the device or driverâs WDF_OBJECT_ATTRIBUTES structureâ a good practice
Yes, it is considered a good practice IF you need your EvtIoXxxx event processing callbacks called at IRQL PASSIVE_LEVEL.
We do not encourage drivers to do this generally unless they have a specific need for their EvtIoXxx callbacks to run at IRQL PASSIVE_LEVEL. But when that need exists, this one of the ways to meet that requirement.
I want to install callout and filters
Iâll just mention, in passing, that I donât understand what you mean by this. But, if youâre happy with the above answer and confident about your current approach, it probably doesnât matter.
Cheers,
Peter
I want to install callout and filters
Iâll just mention, in passing, that I donât understand what you mean by this. But, if youâre happy with the above answer and confident about your current approach, it probably doesnât matter.
Oh, thanks your guide ! Theyâre components of Windows Filtering Platform Callout Driver
For these situations, I use either a dedicated kernel thread, or a kernel
worker routine.
On Tue, Nov 13, 2018 at 11:36 AM iFengHuang
wrote:
> OSR https://community.osr.com/
> iFengHuang commented on Whatâs the correct way to ensure my code run at
> PASSIVE_LEVEL ?
>
> > > I want to install callout and filters
> >
> > Iâll just mention, in passing, that I donât understand what you mean by
> this. But, if youâre happy with the above answer and confident about your
> current approach, it probably doesnât matter.
>
> Oh, thanks your guide ! Theyâre components of Windows Filtering Platform
> Callout Driver
>
> â
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/291425#Comment_291425
>
> Check it out:
> https://community.osr.com/discussion/comment/291425#Comment_291425
>
iFengHuang wrote:
I want to install callout and filters when my driver receives IO request from user-mode application.
I suspect youâre just paraphrasing what you really want here, but thatâs
not how it works. Your driver will be installed using the Service
Manager like all other callout and filter drivers, and it will run all
the time. You can have ioctls to turn your filtering on and off, but
thatâs not âinstallingâ. And if thatâs all the ioctl is doing, it
doesnât really matter whether it runs at DISPATCH_LEVEL.
I suspect youâre just paraphrasing what you really want here, but thatâs
not how it works. Your driver will be installed using the Service
Manager like all other callout and filter drivers, and it will run all
the time. You can have ioctls to turn your filtering on and off, but
thatâs not âinstallingâ. And if thatâs all the ioctl is doing, it
doesnât really matter whether it runs at DISPATCH_LEVEL.
Sorry for my descriptions, I means call FwpsCalloutRegister, FwpmCalloutAdd, FwpmFilterAdd âŚetc when receive ioctl
I use either a dedicated kernel thread, or a kernel worker routine.
It depends on what you want to do, right?
If the OP wants to call out synchronously while processing an IOCTL, then the ârightâ way to do this would be by setting a PASSIVE_LEVEL execution constraint.
If the callout is going to take âsome timeâ to do, then the OP wants to process the operation asynchronously⌠and will want to put the IOCTL aside (put it on, for example, a manual queue) and then use a work item to do the callout. When the callout is complete, the OP would need to take that pending IOCTL off the queue, and complete it.
So⌠it depends.
Peter