locked
Accessing specialized device driver via Read/WriteFile APIs from Metro app

    Question

  • Hi All,

    Forgive me for my plain question - I have no experience in windows driver development and hardly distinguish between umdf and kmdf drivers.

    My problem is:

    I have a specialized device and a custom driver which I'm now accessing via DeviceIOControl and CreateFile/ReadFile/WriteFile combo. I've been tasked with assessing the effort needed to port that solution to work with Metro aps.

    From what I've seen on Build conference presentations and read on MSDN, I know that for making IOCTLs I'll need to author a WinRT proxy component which will call CreateDeviceAccessInstance() (assuming the device interface is already marked as privileged, metadata is there and the app packaging advertises the need for calling custom device).

    The question is: what about the part where my code uses ReadFile/WriteFile?I can see that IDeviceIocontrol interface exposes only IOCTL functions (sync/async versions), but from one of the presentations on Build conference I recall the presenter saying that the only driver-side change required for Win8 is changing one bit of information (i assume this is the 'privileged' property to be set in INF)

    I'm certainly no expert when it comes to drivers, hence the question - can I still use my driver the way I used to in Win8? Is there any interface which'll expose device handle to me (or is it planned to add such interface to  CreateDeviceAccessInstance call?). I've looked at CreateFile2() fn but from what I see in the docs, it is not tailored to work with devices at all.

    To put in in other words - I'm trying to avoid any changes in driver code (actually it is developed by different team in my company so I don't even have its source code yet). Is it possible to access the functions in driver which are responsible for ReadFile/WriteFile handling with some generic IOCTL call? 

    Thanks


    --Matt

    for
    • Edited by warmus Wednesday, March 07, 2012 6:07 PM
    Wednesday, March 07, 2012 6:05 PM

Answers

  • Matt,

    You would need to change these two IOCTLs and or add two additional IOCTLs that did the same thing.  Or you could write a filter driver to modify the reads and writes if you need to not change the driver code for some reason.

    • Marked as answer by warmus Tuesday, March 27, 2012 6:00 AM
    Thursday, March 15, 2012 2:51 AM
    Moderator
  • Matt,

    I do not have exact figures.  However a lot of drivers do use IOCTLs other than READ and WRITE to talk to their device drivers.  Metro style device apps support IOCTLs to specialized devices however not the READ and WRITE IOCTLs. 

    You would want to have in place a method for making driver changes as well as the experience of going through the certification process before deploying your device driver.

    Best Wishes - Eric

    Saturday, March 24, 2012 7:23 PM
    Moderator

All replies

  • Matt,

    What type of device are you using and which bus is it attached to.

    Best Wishes - Eric

    Thursday, March 08, 2012 9:49 PM
    Moderator
  • Eric,

    It's a motherboard/chipset-related system device (class: System) attached to the PCI bus.

    Don't know if it is related, but the device also has FILE_DEVICE_SECURE_OPEN characteristic.


    --Matt

    Thursday, March 08, 2012 10:26 PM
  • The metadata for chipset devices are bound to the PC and thus controlled by the OEM.  Metro style Device Apps can access chipset devices only if access permission is granted by the OEM in the PC metadata. 


    Friday, March 09, 2012 2:41 AM
    Moderator
  • Eric,

    Thanks for your reply. It will be very helpful when I go implementation stage. Until now I wasn't even aware that chipset devices don't have their own metadata package.

    I was assuming (and still am) that the metadata (let it be device-specific or PC-wide) is already OK and my app has access to IDeviceIoControl instance and IOCTLs work.

    But what about the access via Read/WriteFile (or how to access Read/WriteFile handling routines in driver from Metro app?). E.g. a call to CreateDeviceAccessInstance which will give me another interface (IFileAccess or sth like that) is probably what I'm looking for.


    --Matt

    Friday, March 09, 2012 7:14 AM
  • Once you get the source code for the driver you will see how the read and write paths are defined as IOCTLs.  Chances are they are already defined as custom IOCTL codes other than IRP_MJ_READ, IRP_MJ_WRITE.  Will you be getting the source code for the driver?  Also what type of device is this?
    Friday, March 09, 2012 9:47 PM
    Moderator
  • Eric,

    Thanks for your hints. I've finally got access do driver's source code (to be honest - I feel kinda lost in there but I think I grasp the high-level idea :) ). Sadly the function which handles IRP_MJ_DEVICE_CONTROL requests does not look anything like the ones for IRP_MJ_READ or IRP_MJ_WRITE (it just has a couple IOCTLs coded, none of them is even remotelyrelated to the routines used for read/write device).

    So my question is - do I need to make some intrusive changes to the driver or can IRP_MJ_READ/IRM_MJ_WRITE routines be accessed another way?

    Since the device broker has already given me access to the device driver, why can't I use full set of APIs to talk to it? Is this some kind of overlook or a security concern? I'm assuming I'm not the only one facing this issue - is the driver recompilation the only way to go?

    BTW. My device is a custom encryption device (on a very high level of abstraction, it behaves somewhat simmilar to the TPM module, but it does not have its interface or any kind of class driver for that kind).


    --Matt

    Saturday, March 10, 2012 12:57 PM
  • Matt,

    Dos the driver have an IRP_MJ_WRITE and IRP_MJ_READ?

    Best Wishes - Eric

    Wednesday, March 14, 2012 2:02 AM
    Moderator
  • Eric,
    Yes it does have both (and they are unique, in the sense, that the same functionality is *not* exposed via IRP_MJ_DEVICE_CONTROL handler - see my above post for details).


    --Matt

    Wednesday, March 14, 2012 6:57 PM
  • Matt,

    You would need to change these two IOCTLs and or add two additional IOCTLs that did the same thing.  Or you could write a filter driver to modify the reads and writes if you need to not change the driver code for some reason.

    • Marked as answer by warmus Tuesday, March 27, 2012 6:00 AM
    Thursday, March 15, 2012 2:51 AM
    Moderator
  • Eric,

    Than you for your reply. To be honest, changing the driver binary is exactly what I was hoping to avoid (the change itself looks very straightforward, but every driver-related modification seems to have a very large 'administrative' overhead, not to mention WHQL certification and other factors)

    While I understand that some design decisions were made, and that there are cases (like mine) where driver changes are necessary to use a device with Metro, could you at least explain in plain words, why was this change forced?

    What was the rationale behind banning ReadFile/WriteFile-based device access in Metro apps (and allowing only IOCTLs)? Is this a security concern (e.g. can WriteFile bypass device broker?) or an overlook. Or is my driver from an old era and everyone is now using IOCTLs?

    Best wishes, Matt


    --Matt

    Friday, March 16, 2012 8:04 PM
  • Matt,

    I do not have exact figures.  However a lot of drivers do use IOCTLs other than READ and WRITE to talk to their device drivers.  Metro style device apps support IOCTLs to specialized devices however not the READ and WRITE IOCTLs. 

    You would want to have in place a method for making driver changes as well as the experience of going through the certification process before deploying your device driver.

    Best Wishes - Eric

    Saturday, March 24, 2012 7:23 PM
    Moderator
  • The metadata for chipset devices are bound to the PC and thus controlled by the OEM.  Metro style Device Apps can access chipset devices only if access permission is granted by the OEM in the PC metadata. 


    Hi Eric :

    Exactly, how can we do that ? Any document on this ?

    I am planning to have a small firmware driver at our own NB device.

    regards

    Neo Wong

    Monday, March 26, 2012 3:04 PM
  • Neo,

    We will have information available shortly for the motherboard devices.

    Best Wishes - Eric

    Monday, March 26, 2012 7:08 PM
    Moderator
  • (...)Metro style device apps support IOCTLs to specialized devices however not the READ and WRITE IOCTLs. (...)

    Eric,

    Thank you for your answers and confirming that driver changes are, in fact, necessary (in my case) for the device to work with MetroUI.

    I do have one follow-up question though: Is there any chance the Read/Write IOCTLs will be supported in the future? I'd also welcome a brief explanation why were they are not allowed in Metro (as opposite to DeviceIOControl i-face) in the first place

    Thanks,

    Matt


    --Matt

    Tuesday, March 27, 2012 6:10 AM