Hi =) I’m very new to many aspects of NT kernel programming, and was
wondering something about IRP_MJ_DEVICE_CONTROL. I know user-mode NT pretty
well, and know some kernel stuff.
There is a particular file system operation that is only allowed in kernel
mode by ntfs.sys. I’d like to write a driver that provides an IOCTL that a
user-mode process can call to request that operation be done on its behalf.
In the IOCTL buffer, the user-mode process would provide a structure
containing a handle to the target file and the data for the operation.
With the SIoctl driver sample, I got a simple stub for this working: my
driver verifies that the requester has SeRestorePrivilege (*) on device
open, and gets the FILE_OBJECT pointer from an ObReferenceObjectByHandle
call for UserMode during the IOCTL.
What I don’t know is what to do is next. Since I’m in the middle of an IRP,
it seems like calling back into the I/O manager with an FsRtl call is a bad
idea. I don’t know how the I/O manager would handle such recursion, being
inexperienced.
What is the proper way to write an IOCTL handler along these lines? The
only way I can think of is to spawn a thread doing the real work and return
“pending” to the IOCTL, but this seems wasteful.
* It seems to me that an operation that is normally only for the kernel
ought to be restricted to Administrators. =)
Hi =) I’m very new to many aspects of NT kernel programming, and was wondering something about IRP_MJ_DEVICE_CONTROL. I know user-mode NT pretty well, and know some kernel stuff.
There is a particular file system operation that is only allowed in kernel mode by ntfs.sys. I’d like to write a driver that provides an IOCTL that a user-mode process can call to request that operation be done on its behalf. In the IOCTL buffer, the user-mode process would provide a structure containing a handle to the target file and the data for the operation.
With the SIoctl driver sample, I got a simple stub for this working: my driver verifies that the requester has SeRestorePrivilege () on device open, and gets the FILE_OBJECT pointer from an ObReferenceObjectByHandle call for UserMode during the IOCTL.
What I don’t know is what to do is next. Since I’m in the middle of an IRP, it seems like calling back into the I/O manager with an FsRtl call is a bad idea. I don’t know how the I/O manager would handle such recursion, being inexperienced.
What is the proper way to write an IOCTL handler along these lines? The only way I can think of is to spawn a thread doing the real work and return “pending” to the IOCTL, but this seems wasteful.
It seems to me that an operation that is normally only for the kernel ought to be restricted to Administrators. =)
IN GENERAL (he said in capital letters) calling an FtRtl function from your dispatch routine isn’t a problem. It is, in fact, the reason that FsRtl functions exist.
However, it *does* depend on what you’re trying to do, as Mr. Johnson implied.
Remember that the Windows I/O Subsystem is mostly asynchronous. So you have to ask yourself: Are you synchronously processing this IRP, and if so, (a) why, and (b) is that what you really want to do?
In general, we try to avoid policy code like this in drivers. An alternative way of achieving your goal might be to apply appropriate protection to your device object, so that only admins can open it and use the services provided by your driver.
Finally, I don’t know what the SIOCTL sample is… can you elaborate. And if you’re not doing this in KMDF, please do yourself a favor and write this driver using KMDF.