I have a scanner file system mini filter driver using the WDK 8.1 samples.
I'm wondering if I can send the entire file up to the user land application so I can do more complicated calculations such as MD5 Hash or anything else really so that I don't have to write more complicated actions in the mini filter driver but instead in the user land application where I don't mind bringing in windows.h and where I can allocate memory on the heap instead of using ExAllocatePoolWithTag and stuff like that.
Can I pass the entire file up to user land mode in one notification?
If not how would I go about chunking that out and syncing.
Here is the interface for the 8.1 scanner file system mini filter driver sample that dictates the communication between the mini filter driver and the user land application:
/*++
Copyright (c) 1999-2002 Microsoft Corporation
Module Name:
scanuk.h
Abstract:
Header file which contains the structures, type definitions,
constants, global variables and function prototypes that are
shared between kernel and user mode.
Environment:
Kernel & user mode
--*/
#ifndef __SCANUK_H__
#define __SCANUK_H__
//
// Name of port used to communicate
//
const PWSTR ScannerPortName = L"\\ScannerPort";
#define SCANNER_READ_BUFFER_SIZE 1024
typedef struct _SCANNER_NOTIFICATION {
ULONG BytesToScan;
ULONG Reserved; // for quad-word alignement of the Contents structure
UCHAR Contents[SCANNER_READ_BUFFER_SIZE];
} SCANNER_NOTIFICATION, *PSCANNER_NOTIFICATION;
typedef struct _SCANNER_REPLY {
BOOLEAN SafeToOpen;
} SCANNER_REPLY, *PSCANNER_REPLY;
#endif // __SCANUK_H__
Notice how there is a 1024 limit on the buffer size being passed. This means I cannot do the MD5 hash on the entire file in the user land application and then would be forced to do it in the mini filter driver, which I want to avoid, if possible.
And here is the function in the mini filter driver that sends the message to the user land application using the interface above:
//////////////////////////////////////////////////////////////////////////
// Local support routines.
//
/////////////////////////////////////////////////////////////////////////
NTSTATUS
ScannerpScanFileInUserMode (
_In_ PFLT_INSTANCE Instance,
_In_ PFILE_OBJECT FileObject,
_Out_ PBOOLEAN SafeToOpen
)
/*++
Routine Description:
This routine is called to send a request up to user mode to scan a given
file and tell our caller whether it's safe to open this file.
Note that if the scan fails, we set SafeToOpen to TRUE. The scan may fail
because the service hasn't started, or perhaps because this create/cleanup
is for a directory, and there's no data to read & scan.
If we failed creates when the service isn't running, there'd be a
bootstrapping problem -- how would we ever load the .exe for the service?
Arguments:
Instance - Handle to the filter instance for the scanner on this volume.
FileObject - File to be scanned.
SafeToOpen - Set to FALSE if the file is scanned successfully and it contains
foul language.
Return Value:
The status of the operation, hopefully STATUS_SUCCESS. The common failure
status will probably be STATUS_INSUFFICIENT_RESOURCES.
--*/
{
NTSTATUS status = STATUS_SUCCESS;
PVOID buffer = NULL;
ULONG bytesRead;
PSCANNER_NOTIFICATION notification = NULL;
FLT_VOLUME_PROPERTIES volumeProps;
LARGE_INTEGER offset;
ULONG replyLength, length;
PFLT_VOLUME volume = NULL;
*SafeToOpen = TRUE;
//
// If not client port just return.
//
if (ScannerData.ClientPort == NULL) {
return STATUS_SUCCESS;
}
try {
//
// Obtain the volume object .
//
status = FltGetVolumeFromInstance( Instance, &volume );
if (!NT_SUCCESS( status )) {
leave;
}
//
// Determine sector size. Noncached I/O can only be done at sector size offsets, and in lengths which are
// multiples of sector size. A more efficient way is to make this call once and remember the sector size in the
// instance setup routine and setup an instance context where we can cache it.
//
status = FltGetVolumeProperties( volume,
&volumeProps,
sizeof( volumeProps ),
&length );
//
// STATUS_BUFFER_OVERFLOW can be returned - however we only need the properties, not the names
// hence we only check for error status.
//
if (NT_ERROR( status )) {
leave;
}
length = max( SCANNER_READ_BUFFER_SIZE, volumeProps.SectorSize );
//
// Use non-buffered i/o, so allocate aligned pool
//
buffer = FltAllocatePoolAlignedWithTag( Instance,
NonPagedPool,
length,
'nacS' );
if (NULL == buffer) {
status = STATUS_INSUFFICIENT_RESOURCES;
leave;
}
notification = ExAllocatePoolWithTag( NonPagedPool,
sizeof( SCANNER_NOTIFICATION ),
'nacS' );
if(NULL == notification) {
status = STATUS_INSUFFICIENT_RESOURCES;
leave;
}
//
// Read the beginning of the file and pass the contents to user mode.
//
offset.QuadPart = bytesRead = 0;
status = FltReadFile( Instance,
FileObject,
&offset,
length,
buffer,
FLTFL_IO_OPERATION_NON_CACHED |
FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET,
&bytesRead,
NULL,
NULL );
if (NT_SUCCESS( status ) && (0 != bytesRead)) {
notification->BytesToScan = (ULONG) bytesRead;
//
// Copy only as much as the buffer can hold
//
RtlCopyMemory( ¬ification->Contents,
buffer,
min( notification->BytesToScan, SCANNER_READ_BUFFER_SIZE ) );
replyLength = sizeof( SCANNER_REPLY );
status = FltSendMessage( ScannerData.Filter,
&ScannerData.ClientPort,
notification,
sizeof(SCANNER_NOTIFICATION),
notification,
&replyLength,
NULL );
if (STATUS_SUCCESS == status) {
*SafeToOpen = ((PSCANNER_REPLY) notification)->SafeToOpen;
} else {
//
// Couldn't send message
//
DbgPrint( "!!! scanner.sys --- couldn't send message to user-mode to scan file, status 0x%X\n", status );
}
}
} finally {
if (NULL != buffer) {
FltFreePoolAlignedWithTag( Instance, buffer, 'nacS' );
}
if (NULL != notification) {
ExFreePoolWithTag( notification, 'nacS' );
}
if (NULL != volume) {
FltObjectDereference( volume );
}
}
return status;
}
There is no need for such complications. Microsoft already supports crypto in kernel. Check out the CNG library which the kernel itself uses to do its hashing, keys, security related cryptographic processing. If you really insist on sending the file contents to user-mode I would propose a more elegant solution and that is to read the file in the user-mode's process address space.
Yet another alternative I would consider is do the file open myself in the kernel, then call ZwDuplicateObject and create a handle to the file for my user-mode process. Lastly send the user-mode process the handle and let it work with the handle and read/query do what it wants. Again depending on your implementation the user-mode process could close the handle or you could wait and close it in the context of your user-mode process ( Using KeStackAttachProcess for example to attach to its address space ).
Still, I would do all the processing I could do in the kernel because switching contexts all the time is expensive.
Good luck,
Gabriel