Make driver work in non-filter mode

[forderud]

Doc: Creating Device Objects in a Function Driver

PDO open permissions

Have tried:

• FILE_READ_ACCESS | FILE_WRITE_ACCESS
• STANDARD_RIGHTS_ALL
• FILE_ALL_ACCESS
• Combined with/without ShareAccess = FILE_SHARE_WRITE | FILE_SHARE_READ

... but they all lead to IOCTL_HID_GET_FEATURE failing with 0xc0000010 (STATUS_INVALID_DEVICE_REQUEST)

Secure read

Requests need file object with SeTcbPrivilege privilege

https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/enforcing-a-secure-read-for-a-hid-collection

This code leads to a crash:

        BYTE input = 1;
        WDF_MEMORY_DESCRIPTOR inputDesc = {};
        WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&inputDesc, &input, sizeof(input));

        BYTE output = 1;
        WDF_MEMORY_DESCRIPTOR outputDesc = {};
        WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&outputDesc, &output, sizeof(output));

        // enable secure read
        NTSTATUS status = WdfIoTargetSendIoctlSynchronously(localTarget, NULL,
            IOCTL_HID_ENABLE_SECURE_READ,
            &inputDesc, // input
            &outputDesc, // output
            NULL, NULL);
        if (!NT_SUCCESS(status)) {
            DebugPrint(DPFLTR_ERROR_LEVEL, DML_ERR("TailLight: IOCTL_HID_ENABLE_SECURE_READ failed 0x%x"), status);
            return status;
        }

RAW device

#include <devguid.h>

status = WdfPdoInitAssignRawDevice(DeviceInit, &GUID_DEVCLASS_HIDCLASS)
ERROR: WdfPdoInitAssignRawDevice, Error c000000d (STATUS_INVALID_PARAMETER)

Changing to GUID_DEVCLASS_BATTERY does not help.

Local IO target setup

WdfDeviceInitSetIoType

Call: WdfDeviceInitSetIoType(DeviceInit, WdfDeviceIoBuffered) (has no effect on a filter driver)

WdfFdoInitSetFilter impact

WDF filter driver investigation:

WdfFdoInitSetFilter calls:

DeviceInit->Fdo.Filter = TRUE

FxDevice::FdoInitialize calls

SetFilter(DeviceInit->Fdo.Filter);

FxDevice::SetFilter calls:

m_Filter = Value;

NOTICE: FxDefaultIrpHandler::Dispatch always fail with STATUS_INVALID_DEVICE_REQUEST if device is not in filtering mode,

To check:

• SetFilterIoType()
• IsFilter()

[forderud]

Doron_Holan
Oct 2010
Hidclass requires the PFILE_OBJECT that opened the stack for read access in the irp. This is why fwd’ing mouhid’s reads work, they contain the PFILE_OBJECT that mouhid opened. There are two ways you can fix this

pull the PFILE_OBJECT out of the read request you receive and then manually add it to the request after you format it for read (IoGetNextIrpStackLocation(WdfRequestWdmGetIrp(request))->FileObject =<…>;)
register an EvtDeviceFileCreate callback, if the request is asking for read access, send the request down synchronously using the default target and when it comes back successfully, create a new remote IO target, and use WDF_IO_TARGET_OPEN_PARAMS_INIT_EXISTING_DEVICE for the open params, passing WdfDeviceWdmGetAttachedDevice for the existing device, then assign openParams.TargetFileObject to the open request’s PFILE_OBJECT and then open the target. Then use this new io target when you format and send your own reads.
d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, October 28, 2010 11:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_PRIVILEGE_NOT_HELD on a Read in a HID filter driver.

Hi,

I wrote a HID filter driver that sits below mousehid. The attempt is to park the IoReads coming from mousehid and generate new multiple IoReads to be sent down the default iotarget.

For the new requests, the sequence is WdfRequestCreate, WdfMemoryCreate, WdfIoTargetFormatRequestFromRead, WdfRequestSend. Pretty much like in the serial.c sample of the WDK. The only difference, which I hope doesn’t really matter, is that the new requests have a context of a few bytes with some info that I reuse later on.

Now, if I forward the IoRead coming from mousehid everything works fine. If I try to feed the iotarget with my ioreads, the completion routine gets called synchronously with WdfRequestSend returning status c0000061 (which is STATUS_PRIVILEGE_NOT_HELD).

I hardly believe the problem is actually a privilege one unless there is something in the requests of mousehid that the lower iotarget uses as a sort of token.

Does this ring a bell to anyone?

Thanks a lot in advance,
Marco.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[forderud]

Doron_Holan
Sep 2013
Are you sure that IoGetCurrentIrpStackLocation(WdfRequestWdmGetIrp(Request))->FileObject is returning a non NULL value? Also, has hidclass seen the IRP_MJ_CREATE for this file handle so it can set up the FileObject the way it needs to? STATUS_PRIVILEGE_NOT_HELD is returned if the file object pointer is NULL OR if it is valid but FsContext is NULL. FsContext is allocated and setup by HIDCLASS in MJ_CREATE processing

d