USBDK -- another Windows generic USB driver

Interestingly Redhat is now developing a new generic USB driver
for Windows even though I see no future of another generic
USB driver for Windows other than WinUSB.

UsbDk documentation:

  1. Short presentation:
    http://www.spice-space.org/docs/usbdk/UsbDk_at_a_Glance.pdf
  2. SDM: http://www.spice-space.org/docs/usbdk/UsbDk_Software_Development_Manual.pdf
  3. UsbDk architecture specificatin (part of source tree):
    http://cgit.freedesktop.org/spice/win32/usbdk/tree/ARCHITECTURE

From the architecture, it seems interesting but potentially dangerous.
Will it really work?

+++++++++++++++++++++++++++++++++++++
Kernel mode component (UsbDk.sys) design and functionality

UsbDk.sys is both USB filter driver and generic USB device driver.
On installation it is being registered as USB filter driver and
system invokes it for each new USB device being discovered including
USB hubs. On invocation UsbDk.sys checks type of underlying device
and creates filter instances for USB hubs only.

Being a filter of USB hub UsbDk.sys receives all requests from upper
part of USB stack including enumeration requests that originated by
PNP manager (IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS).

Upon enumeration request completion by USB hub driver UsbDk.sys scans
array of child devices returned and in case there are devices to be
redirected (according to current configuration) it attaches as filter
to those devices as well.

As a result all PNP manager requests pass via UsbDk.sys callbacks and the
latter patches device ID properties as needed to make PNP manager recognize
the device as a generic USB device.

Besides that UsbDk.sys marks underlying device object as raw PDO so the system
assigns the driver who created it (UsbDk.sys) to be the device driver as well.

At this stage any request to this vendor specific device will be forwarded
to UsbDk.sys which in turn will patch and pass requests to/from original device
created by USB hub as needed.

There is also a separate API provided by UsbDkHelper.dll intended to detach
USB device from USB stack without acquiring actual access to the
device (hider API).

This API may be useful for security applications that need to deny access
to USB devices according to security policy or to prevent Windows from showing
“New Hardware” pop-ups for devices solely managed by UsbDk. When UsbDk.sys
discovers device to be hidden during enumeration phase
(IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS) it wipes corresponding PDO from
device array returned by underlying USB bus driver, this effectively hides
given device from PNP manager and OS driver stack.
+++++++++++++++++++++++++++++++++++++++++++++


Xiaofan

On Tue, Aug 18, 2015 at 1:20 PM, Xiaofan Chen wrote:
> Interestingly Redhat is now developing a new generic USB driver
> for Windows even though I see no future of another generic
> USB driver for Windows other than WinUSB.
>
> UsbDk documentation:
> 1. Short presentation:
> http://www.spice-space.org/docs/usbdk/UsbDk_at_a_Glance.pdf
> 2. SDM: http://www.spice-space.org/docs/usbdk/UsbDk_Software_Development_Manual.pdf
> 3. UsbDk architecture specificatin (part of source tree):
> http://cgit.freedesktop.org/spice/win32/usbdk/tree/ARCHITECTURE
>
> From the architecture, it seems interesting but potentially dangerous.
> Will it really work?
>

BTW, the license is good, it is Apache 2.0.


Xiaofan

Huh, this is really interesting…

On Mon, Aug 17, 2015 at 10:22 PM, Xiaofan Chen wrote:

> On Tue, Aug 18, 2015 at 1:20 PM, Xiaofan Chen wrote:
> > Interestingly Redhat is now developing a new generic USB driver
> > for Windows even though I see no future of another generic
> > USB driver for Windows other than WinUSB.
> >
> > UsbDk documentation:
> > 1. Short presentation:
> > http://www.spice-space.org/docs/usbdk/UsbDk_at_a_Glance.pdf
> > 2. SDM:
> http://www.spice-space.org/docs/usbdk/UsbDk_Software_Development_Manual.pdf
> > 3. UsbDk architecture specificatin (part of source tree):
> > http://cgit.freedesktop.org/spice/win32/usbdk/tree/ARCHITECTURE
> >
> > From the architecture, it seems interesting but potentially dangerous.
> > Will it really work?
> >
>
> BTW, the license is good, it is Apache 2.0.
>
> –
> Xiaofan
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

Anybody have any insight as to WHY they would develop this?

Peter
OSR
@OSRDrivers

Sure - to support virtualization. RHAT is putting lots of resources into
KVM. PV USB is part of that. Not clear how this works for them on the
client side, - perhaps they want to hang PV USB devices off of emulated
host controller root hubs?

Mark Roddy

On Tue, Aug 18, 2015 at 8:03 AM, wrote:

> Anybody have any insight as to WHY they would develop this?
>
> Peter
> OSR
> @OSRDrivers
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

The main purpose is to support USB devices redirection from Spice client machines to VMs. WinUSB had several limitations that we wanted to overcome. Including no support for isochronous transfer on older Windows versions.

Best regards,
Yan.

Does NOBODY EVER read the date on the posts to which they’re replying?

@Yan_Vugenfirer-4 … you’re replying to a 5 year old post. Do you actual think that’s helpful?

Locking this thread…

Peter