Hi, all
I’d like to ask you the following:
Should my minifilter callbacks be called when I/O is issued in the context
of the system process?
I will be more specific: if a system thread calls DriverEntry routine of
some other driver (on behalf of a usermode app which is willing to load this
driver), I see the image_name.sys of this driver being mapped to the system
process address space (within my LoadImagNotifyRoutine), but my callbacks
(PreRead, PreWrite etc) are not being called during the
FltpPerformPreCallbacks() by the filter manager.
Is this normal or am I missing something?
Is there some kind of protection mechanism which disallows lame driver
writers (like myself) to tamper with system I/O which is crucial to OS
stability?
Regards,
Dmitry
> Is there some kind of protection mechanism which disallows lame driver
writers (like myself) to tamper with system I/O which is crucial to OS
stability?
I do not think any Windows software has such mechanisms.
Check a) whether paging IO filtering for all other files is filtered OK b) the driver is not the boot one, the boot drivers are loaded by NTLDR/BOOTMGR together with the kernel and no filters are present in the boot loader.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
When loading a driver, you will not see read (and definitely not write)
operations on the driver file. Instead it creates a section object which
maps the driver file in memory.
//Daniel
“Dmitry G” wrote in message news:xxxxx@ntfsd…
> Hi, all
>
> I’d like to ask you the following:
>
> Should my minifilter callbacks be called when I/O is issued in the context
> of the system process?
>
> I will be more specific: if a system thread calls DriverEntry routine of
> some other driver (on behalf of a usermode app which is willing to load
> this driver), I see the image_name.sys of this driver being mapped to the
> system process address space (within my LoadImagNotifyRoutine), but my
> callbacks (PreRead, PreWrite etc) are not being called during the
> FltpPerformPreCallbacks() by the filter manager.
>
> Is this normal or am I missing something?
>
> Is there some kind of protection mechanism which disallows lame driver
> writers (like myself) to tamper with system I/O which is crucial to OS
> stability?
>
> Regards,
>
> Dmitry
>
>
>
>
Yes, but in order to mapy anything into memory isn’t it supposed to read the
.sys file first?
Dmitry
wrote in message news:xxxxx@ntfsd…
> When loading a driver, you will not see read (and definitely not write)
> operations on the driver file. Instead it creates a section object which
> maps the driver file in memory.
>
> //Daniel
>
>
>
> “Dmitry G” wrote in message news:xxxxx@ntfsd…
>> Hi, all
>>
>> I’d like to ask you the following:
>>
>> Should my minifilter callbacks be called when I/O is issued in the
>> context of the system process?
>>
>> I will be more specific: if a system thread calls DriverEntry routine of
>> some other driver (on behalf of a usermode app which is willing to load
>> this driver), I see the image_name.sys of this driver being mapped to the
>> system process address space (within my LoadImagNotifyRoutine), but my
>> callbacks (PreRead, PreWrite etc) are not being called during the
>> FltpPerformPreCallbacks() by the filter manager.
>>
>> Is this normal or am I missing something?
>>
>> Is there some kind of protection mechanism which disallows lame driver
>> writers (like myself) to tamper with system I/O which is crucial to OS
>> stability?
>>
>> Regards,
>>
>> Dmitry
>>
>>
>>
>>
>
>
> When loading a driver, you will not see read (and definitely not write)
operations on the driver file. Instead it creates a section object which
maps the driver file in memory.
…and then reads all these pages to paged pool and locks the ones which do not belong in PAGExxxx sections.
You can delete and replace the .SYS file for a loaded driver. Really so. Memory-mapping is not used for drivers as for DLLs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
For a memory-mapped binary image file, at least the header is read immediately within MmCreateSection. At least there is a need to check that this is really a PE file 
But drivers are not loaded using memory-mapped files.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Dmitry G” wrote in message news:xxxxx@ntfsd…
> Yes, but in order to mapy anything into memory isn’t it supposed to read the
> .sys file first?
>
> Dmitry
>
> wrote in message news:xxxxx@ntfsd…
>> When loading a driver, you will not see read (and definitely not write)
>> operations on the driver file. Instead it creates a section object which
>> maps the driver file in memory.
>>
>> //Daniel
>>
>>
>>
>> “Dmitry G” wrote in message news:xxxxx@ntfsd…
>>> Hi, all
>>>
>>> I’d like to ask you the following:
>>>
>>> Should my minifilter callbacks be called when I/O is issued in the
>>> context of the system process?
>>>
>>> I will be more specific: if a system thread calls DriverEntry routine of
>>> some other driver (on behalf of a usermode app which is willing to load
>>> this driver), I see the image_name.sys of this driver being mapped to the
>>> system process address space (within my LoadImagNotifyRoutine), but my
>>> callbacks (PreRead, PreWrite etc) are not being called during the
>>> FltpPerformPreCallbacks() by the filter manager.
>>>
>>> Is this normal or am I missing something?
>>>
>>> Is there some kind of protection mechanism which disallows lame driver
>>> writers (like myself) to tamper with system I/O which is crucial to OS
>>> stability?
>>>
>>> Regards,
>>>
>>> Dmitry
>>>
>>>
>>>
>>>
>>
>>
>
>
>
That you can delete and replace a sys file in use does not give a guarantee
about the way it is loaded. This mapping is only done to load the image, not
while the image is executed. I just stepped through the code of
NtLoadDriver to see what happens, it appears it creates a work item which
calls MmCreateSection and MiCreateImageFileMap, them MiLoadSystemImage maps
a view of the image section.
You will not receive IRP_MJ_READ IRPs for the loading of a driver, you will
receive however receive IRPs such as
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION.
//Daniel
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> When loading a driver, you will not see read (and definitely not write)
> operations on the driver file. Instead it creates a section object which
> maps the driver file in memory.
…and then reads all these pages to paged pool and locks the ones which do
not belong in PAGExxxx sections.
You can delete and replace the .SYS file for a loaded driver. Really so.
Memory-mapping is not used for drivers as for DLLs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> NtLoadDriver to see what happens, it appears it creates a work item which
calls MmCreateSection and MiCreateImageFileMap, them MiLoadSystemImage maps
a view of the image section.
You will not receive IRP_MJ_READ IRPs for the loading of a driver
Then MiCreateImageFileMap surely reads the 1st page of the file to parse and validate the PE header.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim and Daniel,
thanks for your inspirational comments.
Dmitry.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> NtLoadDriver to see what happens, it appears it creates a work item which
> calls MmCreateSection and MiCreateImageFileMap, them MiLoadSystemImage
> maps
> a view of the image section.
>
> You will not receive IRP_MJ_READ IRPs for the loading of a driver
Then MiCreateImageFileMap surely reads the 1st page of the file to parse and
validate the PE header.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
It seems that it is reading complete file, the sys file size is 11648 bytes (0x2D80)
I loaded scanner from fltmc and following is the output from filespy.
System IRP_MJ_CREATE 00000884 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FILE_OPEN CreOpts: 0 Access: 00000020 Share: 00000005 Attrib: 0 Result: FILE_OPENED
System FASTIO_QUERY_STANDARD_INFO C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FileStandardInformation AllocationSize: 00000000-00003000 EndOfFile: 00000000-00002D80 NumberOfLinks: 1 DeletePending: 0
System IRP_MJ_QUERY_INFORMATION 00000874 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FileStandardInformation AllocationSize: 00000000-00003000 EndOfFile: 00000000-00002D80 NumberOfLinks: 1 DeletePending: 0
/*=======READ=======*/
System IRP_MJ_READ 00000043 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS Offset 00000000-00000000 ToRead 3000 Read 2D80
/*=======READ=======*/
System IRP_MJ_QUERY_INFORMATION 00000014 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FileNameInformation
System FASTIO_QUERY_STANDARD_INFO C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FileStandardInformation AllocationSize: 00000000-00003000 EndOfFile: 00000000-00002D80 NumberOfLinks: 1 DeletePending: 0
System FASTIO_QUERY_STANDARD_INFO C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS FileStandardInformation AllocationSize: 00000000-00003000 EndOfFile: 00000000-00002D80 NumberOfLinks: 1 DeletePending: 0
System IRP_MJ_CLEANUP 00000404 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS
System IRP_MJ_CLOSE 00000404 C:\WINDOWS\system32\DRIVERS\scanner.sys STATUS_SUCCESS
>When loading a driver, you will not see read (and definitely not write) operations on the driver file. Instead it creates a section object which maps the driver file in memory.
One more point of confusion I have from the statement is “even if a sys file is mapped, there should be a read operation to support that”, as otherwise how come it will work with some encryption filter driver.
for example: The sys file in disk is encrypted and a filter driver is doing decryption in non cached read handlers. So if there will be no read operations than it will surly fails(who will understand encrypted data). I saw this with exe and do not found any reason to think that it will not be same in case of sys file.
Thanks,
Aditya
Right, what apparently happens is that only the first time the driver is
loaded the file is loaded (with IoPageRead) but not any subsequent times
after you have unloaded it and load it again, probably because it still has
a copy in memory.
//Daniel
wrote in message news:xxxxx@ntfsd…
> One more point of confusion I have from the statement is “even if a sys
> file is mapped, there should be a read operation to support that”, as
> otherwise how come it will work with some encryption filter driver.
>
> for example: The sys file in disk is encrypted and a filter driver is
> doing decryption in non cached read handlers. So if there will be no read
> operations than it will surly fails(who will understand encrypted data). I
> saw this with exe and do not found any reason to think that it will not be
> same in case of sys file.
>
> Thanks,
> Aditya
>