Trying to use Dmf_IoctlHandler with Control Device Object, supported?
nefarius opened this issue · comments
I replaced a lot of verbose code with Dmf_IoctlHandler on my control device but I found multiple issues in doing so. While it seems to "work" the way I want, Driver Verifier has several complaints:
DMF_DmfControlDeviceInitAllocate
DMF_DmfControlDeviceInitAllocate behaves slightly differently depending on supplying a PWDFDEVICE_INIT or NULL, but both logic branches set dmfDeviceInit->FileObjectConfigHooked to TRUE, which triggers the assert in DMF_DmfDeviceInitHookFileObjectConfig because it thinks the hooks have been set already. Is this intentional? Am I using it wrong?
DMF_DmfDeviceInitHookFileObjectConfig
If I omit calling DMF_DmfDeviceInitHookFileObjectConfig my IOCTL handlers get fired but now ofc. the module won't get its file object hooks called so depending on the use case it's only partially operable. E.g. checking administrative access will not work.
I hope I could explain my setup well enough, am wondering if it's working as intended or an oversight.
Cheers
Ok, so I am unable to find an example of where we use IoctlHandler with a Control Device. I have plenty of examples of both independently but not together. So, let me try to make such a driver and see what happens. I will try to do it by end of the week.
DMF has this API DMF_FilterControl_DeviceCreate(). My feeling is that i will use that and try to hook up IoctlHandler that. In the meantime, I am not sure if you used that. You might look at that and see if that helps at all in the meantime in case you have time.
I looked at that already, my main problem is that I need to register the file I/O callbacks for my use-case, it works already, but verifier complains because the asserts trigger. Obviously they only do in debug builds but the asserts are there for a reason, so I don't just want to ignore them and call it a day.
Here's the assert:
*** Assertion failed: DmfDeviceInit->FileObjectConfigHooked != TRUEDmfDeviceInit->FileObjectConfigHooked != 1
*** Source File: C:\Users\BenjaminHöglinger-St\Documents\DMF\Dmf\Framework\DmfDeviceInit.c, line 1058
Here is the relevant snippet from my control device creation:
pInit = WdfControlDeviceInitAllocate(
WdfDeviceGetDriver(Device),
// Required for unprivileged process access
&SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX
);
if (pInit == nullptr)
{
status = STATUS_INSUFFICIENT_RESOURCES;
TraceError(
TRACE_SIDEBAND,
"WdfControlDeviceInitAllocate failed with %!STATUS!",
status
);
break;
}
dmfDeviceInit = DMF_DmfControlDeviceInitAllocate(pInit);
if (dmfDeviceInit == nullptr)
{
TraceError(
TRACE_DRIVER,
"DMF_DmfDeviceInitAllocate failed"
);
status = STATUS_INSUFFICIENT_RESOURCES;
break;
}
DMF_DmfControlDeviceInitSetClientDriverDevice(dmfDeviceInit, Device);
//
// Exclusive access OFF, allows multiple handles
//
WdfDeviceInitSetExclusive(pInit, FALSE);
//
// Assign name to expose
//
if (!NT_SUCCESS(status = WdfDeviceInitAssignName(pInit, &ntDeviceName)))
{
TraceError(
TRACE_SIDEBAND,
"WdfDeviceInitAssignName failed with %!STATUS!",
status
);
break;
}
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, FILE_HANDLE_CONTEXT);
attributes.SynchronizationScope = WdfSynchronizationScopeNone;
//
// File object hooks and callbacks
//
WDF_FILEOBJECT_CONFIG fileObjConfig;
WDF_FILEOBJECT_CONFIG_INIT(
&fileObjConfig,
Sideband_EvtWdfDeviceFileCreate,
Sideband_EvtWdfFileClose,
WDF_NO_EVENT_CALLBACK // No cleanup callback function
);
fileObjConfig.FileObjectClass = WdfFileObjectWdfCanUseFsContext;
/*
* TODO: triggers Driver Verifier!
* See: https://github.com/microsoft/DMF/issues/228
*/
//DMF_DmfDeviceInitHookFileObjectConfig(dmfDeviceInit, &fileObjConfig);
WdfDeviceInitSetFileObjectConfig(
pInit,
&fileObjConfig,
&attributes
);
//
// Prepare device object creation
//
WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CONTROL_DEVICE_CONTEXT);
attributes.EvtCleanupCallback = Sideband_DeviceContextCleanup;
if (!NT_SUCCESS(status = WdfDeviceCreate(
&pInit,
&attributes,
&controlDevice
)))
{
TraceError(
TRACE_SIDEBAND,
"WdfDeviceCreate failed with %!STATUS!",
status
);
break;
}Ok, I see. It is not Driver Verifier that is asserting. It is just a plain assert emitted by DMF in DEBUG build... Definitely you should not ignore it. (Driver Verifier asserts are emitted by the OS/WDF.)
Correct, pardon the confusion, I debugged multiple issues in the same session, so I got the terms mixed up a bit.
Hi Benjamin,
I have reproduced the issue. To clarify, this issue is not directly related with DMF_IoctlHandler. DMF_IoctlHandler is supported for Control Device objects.
The problem you are having is simply the call to DMF_DmfDeviceInitHookFileObjectConfig(). (You don't need to call this function to use DMF_IoctlHandler. You are calling it because your driver needs use WdfDeviceInitSetFileObjectConfig()to set the WDF_FILEOBJECT Create/Close callbacks and set the specific attribute. Because of that you have to callDMF_DmfDeviceInitHookFileObjectConfig()`.
I have reproduced the issue using a private driver and I am trying to determine what to do about it.
I will try to update this issue later today after I discuss with my colleagues. Thank you for patience and especially for your feedback.
Hi Benjamin,
OK, here is the proposed fix for the issue you found:
Can you try it and verify it works for you?
We still need to do some validation on our end. There was actually another issue the PR corrects where the FileClose callback would not be called. I have updated the NonPnp1 sample to verify that all the WDFFILEOBJECT callbacks are called. I have tried running multiple instances of the application as well as abnormal termination, etc. It all looks good to me.
You always give great feedback and we all here appreciate it.
I will close this issue once you verify you are happy with it. We basically use option one above to allow the call to proceed without assert for Control Devices.
Thank you
Great! Will test midweek when I'm back at this particular project.
This fix has been merged into master, Release v1.1.130.
https://github.com/microsoft/DMF/releases/tag/v1.1.130
Once you verify it, we can close this issue.
Sorry for the delay, it's been a surprisingly busy week so far!
Just came around to test on my end, everything looks good now, thank you!