Hey,
I’m writing a logging kernel driver that writes its logs to an attached serial port. This is going to log data coming from a minifilter and a wfp filter (I’m not sure if this possible but this is the plan). And from what I understood, callback from minifilters and wfp filters are not guaranteed to be running at IRQL = PASSIVE_LEVEL so I can’t use ZwCreateFile and IoGetDeviceObjectPointer. And since I’ll be building this as an export driver to be used by the filter drivers, I couldn’t used the wdf functions as a KMDF driver can’t be an export driver. So, how should I acquire serial port’s device object to write to it ?
PS: To conform to the rules, I’m a student and this is for an academic project.
Create a user mode service that does your logging. Your export driver creates a named device object that your service opens for asynchronous operations. The driver and service have a defined IOCTL for passing log messages from the driver to the service. The service opens the serial port, not the driver. The service issues some number of your defined logging IOCTLS and waits for completion. Your driver can complete IO requests at any IRQL <= DISPATCH_LEVEL. The service, on IOCTL completion, writes the log data from the completed IOCTL to the log device (the serial port) and issues another async IOCTL to keep the queue full on the driver side.
I get your idea and I think it would be more robust than my current architecture but I guess It’s too complicated for me to implement at this level. In fact, I have already found an open source logging driver I’m going to port to implement my serial port logging which already deals with buffering and synchronisation. So, I’d prefer to figure out a way to open my serial port from this kernel driver.
Are you thinking about opening the com port on demand within the logging function? Instead, export an Init() function from the export driver and open the com port from there the first time Init executes. Then use the com port device object as is in the Log() export function.
1 Like
Oh, I was under the impression all the related functions had the same IRQL constraint. Thank you for the idea I guess this is what I’m going to do then !
Doron’s advice is key – open the file once, not every time. The first time you’re called, you can always use ExQueueWorkItem to queue up a work item, which is a callback that runs at passive level.
Roll your own IO (IRP or WDFEQUEST) can be sent at dispatch to a serial port without the work item. The Zw Io APIs require passive.
Yeah but can I use WDFREQUEST outside KMDF ?