Alternative to events to wake-up PsSetCreateProcessNotifyRoutineEx callback from user-mode

NTDEV
1

Hi All,

We are developing a AV engine to monitor process creation. Software driver hooks to PsSetCreateProcessNotifyRoutineEx and informs the user-mode about process creation event, and then waits for the decision by user-mode service.

The current design is to create a data-structure which describes the process creation in a data structure (PID, image path, MD5, etc along with a event) and then insert in to a driver specific queue. Once inserted in the queue, process creation callback will block on the event created.

The user-mode service will continuously keep reading the pending items in the queue using an IOCTL.
The user-mode service will then run the decision engine, and sends back response to driver using a IOCTL. Once driver receives response inside another IOCTL handler, it will set the corresponding event in the queue item which will unblock callback routing.

Need your help in below considerations:

  • What should be the size of the driver queue? My understanding is that process creation/deletion is not serialized by Windows. Hence, we can have multiple process creation requests at the same time.
    Idea is to create a LINKED LIST with fixed number of elements, and each LIST element will have a unique number, service-program final decision and an EVENT. But, this might result in LIST overflow if service program takes more time to provide decision. What is the best way to make the LINKED LIST dynamic. Is it a good idea to allocate LIST ITEM dynamically for each process create callback with ExAllocatePoolWithTag?? or follow some other method to make LIST truly dynamic. And also, thoughts on memory fragmentation and how to avoid??

  • Creating an event for each creation call, is it a good idea? I am worried about large number of events that we will have to create.

  • And need to handle the cases where user-mode service program dies because of a crash or manual sc stop. In that case, driver should not be blocked to create the processes.

Thanks for your help in advance,
Reddy

2

Is it a good idea to allocate LIST ITEM dynamically for each process create callback with ExAllocatePoolWithTag?? or follow some other method to make LIST truly dynamic. And also, thoughts on memory fragmentation and how to avoid??

Why would this NOT be a good idea? Unless you are on a tiny, IOT Core system, there is absolutely no reason to worry about memory fragmentation. And probably not even then. If you fear memory exhaustion, then you COULD pre-allocate the list… but I can tell you that any number of pre-allocated elements you choose will be wrong at some point in time. You’ll either have allocated too many entries, or too few entries for any given circumstance. You could, of course, use a look-aside list (of your own creation or a Windows provided one). But that a whole other discussion.

Creating an event for each creation call, is it a good idea? I am worried about large number of events that we will have to create.

The I/O Manager quite nicely handles millions of I/O events per second. To handle each one, it needs to allocate (at least) an IRP. I think that works quite well. So, unless by “large number of events” you mean MILLIONS per second, I think you’re likely to be OK.

And need to handle the cases where user-mode service program dies because of a crash or manual sc stop. In that case, driver should not be blocked to create the processes.

OK. So, handle that in your code.

Basically, you’re suffering from a case of premature optimization. I want you to get a piece of paper (8.5x11, or A4 size)… and I want you to write on it, in landscape mode, in large (3cm or more high) letters:

Make it work first.
Then make it work fast.

This is a standard OSR slogan. Once you’ve got things WORKING… then IF things are slow, THEN figure out how to make them faster. Not only is it good engineering, it makes you look good with your boss/customer: “Look at the performance improvement we’ve been able to make!”

Peter

3

:slight_smile: Thanks Peter for your inputs.
100% agree with what you said:

Make it work first.
Then make it work fast.