What's the correct way to ensure my code run at PASSIVE_LEVEL ?

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 :smile:

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 :smile:

@Jamey_Kirby said:
For these situations, I use either a dedicated kernel thread, or a kernel
worker routine.
Thanks your proposal, I will have a try. :smile:

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

@“Peter_Viscarola_(OSR)” said:

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

Thx, I understand now :smiley: