Breaking down the source code into smaller pieces
hdi-amiri opened this issue · 3 comments
After compiling the source code successfully, I am trying to understand the core functionality of this tool which is blocking process execution on some criteria.
In this line of code we are requesting the user-land to tell us what should we do with this newly created process, I was wondering if the driver is blocked in this line of code? Say if we have 10 newly created processes what really happens?
This method defined here does the job of informing the driver which is mostly called in pfworker.cpp
like here. When the service is started running, the call to DriverInit()
initializes the driver and loads it and create a thread which runs the WINAPI
function ep_DriverService
. this function also runs PfWorkerWork
in another thread, PfWorkerWork
is the function that writes the response to the driver back. How this PfWorkerWork
is connected with core
api's ProcFilterEvent
defined here?
The thread creating the process will be blocked in the kernel until the userland service responds with a scan result. A single thread can only create 1 process at once and the scan is performed as part of the new process being created. Creation of 10 processes is not a parallel operation from the perspective of a single thread. To the thread creating the process, the ProcFilter scan is just part of the overhead of creation. If there were multiple threads creating multiple processes simultaneously, each thread would block in parallel with each other since they're separate events and would be handled separately.
PfWorkerWork is connected to the API via ApiEventExport() defined at
Line 1289 in 560a7b9
procfilter/service/pfworker.cpp
Line 202 in 560a7b9
Does this help?
Yeah, Pretty sure it helped a lot, Since I am very new to driver development I find a lot of things going on here strange. Are you using Inverted Call model for communicating between driver and service?
Yes, I believe it is similar. https://github.com/godaddy/procfilter/blob/master/driver/kmdriver.cpp#L824 Is the section that decides how to react to a read request from the service. The decision is whether to complete the read immediately with data or to mark the read as pending, just as any other I/O operation where data is not available yet.