Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Disable USB-C ports

s0ckzzs0ckzz Member Posts: 8
edited November 13 in NTDEV

Guys,

Is it possible to disable individual USB-C ports on a Windows system using a filter driver, selective suspend or something similar? The filter driver could be used to intercept PNP calls and "hide" information to the system somehow?

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,695

    The most reliable way to disable USB-C ports is to fill them with silicone sealant.

    There are group policies to block certain kinds of USB devices. That's usually what you want. Note that there's no reliable way for a driver to know where ports are physically located.

    I don't think you understand what selective suspend is for.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • s0ckzzs0ckzz Member Posts: 8

    Got it, so selective suspend is not a good way.

    Regarding the USB ports, what you're trying to say is "there's no generic way to do that". So, the viable way would be to have lower level access, like, some ACPI methods exposed for me to do that or something like that?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,158

    You're throwing around a lot of terminology, but it doesn't seem like you have a good idea of how the principles related to that terminology work in Windows. "Selective suspend"? "ACPI methods"? Let me guess... you're primarily a hardware person?? It's OK if you are. Some of my best friends are hardware people... ;-)

    Look: The bottom line here is that you're going to need to tell us more about what you want to do.

    It is entirely possible to write a filter driver that will block the attachment of USB devices. What Mr. Roberts was saying, and quite correctly too, is that it's exceedingly difficult to know a-priori the internal topology for a given physical USB port on your computer. That is, you can pretty easily POINT to the port you want to block, but knowing WHICH port that is internally (from your driver) isn't simple... or likely even possible.

    Now, if you're making an embedded system, where the configuration of every machine is predictably the same... then, well, maybe there's a way.

    Or if you just don't want ANY devices to be connected via USB, there are certainly ways to accomplish that.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • s0ckzzs0ckzz Member Posts: 8

    Haha I'm a software guy but I'm really new into Driver Development so I don't know the concepts very well and I'm learning what I can.
    Thanks a lot for the patience, guys.

    Anyways, let me try to clarify. I have an specific Windows Workstation (the hardware is fixed, for the moment, so I think it's easier to try to map the "logical port" to the physical port) that I want to be able to disable specific USB-C ports (for example, an application that an Administrator can check which ports are enabled or not, by user, etc.). Here's what I thought:

    • The best scenario (if possible): the user plugs any device - it won't even power on. So I thought I could use the selective suspend somehow to reduce the power to a device. But I don't know if it's a good way because selective suspend must be supported, right? By the controller? By the device? By both?;
    • The acceptable scenario: Use a filter driver to block the attachment of USB devices - the hardware is fixed, so I think I can guess the physical port, right? The device will power on but it will not be shown in Device Manager.

    I'm ok with the "acceptable scenario". Do you guys think it's feasible? What would I need? A Lower-Level Filter Driver? Is there any sample that could me help to achieve this feature?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,158

    That's MUCH more clear. Thanks.

    Well... Hmmmm... I haven't tried it, but at least theoretically if you could identify which port, on which hub, you wanted to power off, you should be able to power it off using Clear Hub Feature with the "feature selector" being PORT_POWER. See page 437 of the USB 3.2 spec. Just in case you're not aware (no offense, but I have no way of knowing what you know about the basics of USB)... every USB port is managed by a hub, even the ones that come right off the USB controller. The USB Host Controller always has (one or more) integral hubs associated with it. It's the USB HUB driver (and not the USB Host Controller Driver) the enumerates newly arrived USB devices.

    So... that could be a way forward for you.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,695

    Peter gave a good answer, much better than my snarky one. I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system, as yours is, so my sarcasm boils to the surface.

    The problem with selective suspend is that it is managed by the hub driver, based on the current state of the system and its child devices. There's no way for you to interfere in its decision process. If you tried to force a port into selective suspend, the hub driver would stubbornly put things back.

    However, the PORT_POWER thing is a possibility. You can shut down individual ports that way. I'm not sure it would survive sleep/resume, but that's an issue you could work on. Most hubs can be addressed from user mode; I'm not sure you'd even need a driver. Look, for example, at the USBView sample app. It communicates directly with the hubs to get the information it needs.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • s0ckzzs0ckzz Member Posts: 8

    @Peter_Viscarola_(OSR) said:
    That's MUCH more clear. Thanks.

    Well... Hmmmm... I haven't tried it, but at least theoretically if you could identify which port, on which hub, you wanted to power off, you should be able to power it off using Clear Hub Feature with the "feature selector" being PORT_POWER. See page 437 of the USB 3.2 spec. Just in case you're not aware (no offense, but I have no way of knowing what you know about the basics of USB)... every USB port is managed by a hub, even the ones that come right off the USB controller. The USB Host Controller always has (one or more) integral hubs associated with it. It's the USB HUB driver (and not the USB Host Controller Driver) the enumerates newly arrived USB devices.

    So... that could be a way forward for you.

    Peter

    Hmmm nice, I wasn't aware. Thanks a lot for the informations. I'll study the feature you talked on the spec. Thanks a lot for all the information.

  • s0ckzzs0ckzz Member Posts: 8
    edited November 13

    @Tim_Roberts said:
    Peter gave a good answer, much better than my snarky one. I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system, as yours is, so my sarcasm boils to the surface.

    The problem with selective suspend is that it is managed by the hub driver, based on the current state of the system and its child devices. There's no way for you to interfere in its decision process. If you tried to force a port into selective suspend, the hub driver would stubbornly put things back.

    However, the PORT_POWER thing is a possibility. You can shut down individual ports that way. I'm not sure it would survive sleep/resume, but that's an issue you could work on. Most hubs can be addressed from user mode; I'm not sure you'd even need a driver. Look, for example, at the USBView sample app. It communicates directly with the hubs to get the information it needs.

    No problem about the snarky answer haha :-) I laughed out loud, actually.

    Regarding the hubs addressable from user mode, that's great news. I'll look into that also. Thank you!

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,158

    I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system

    Ordinarily, me too. But, you know, not every system running Windows is an "ordinary" Windows system. Consider systems that are used to host machine tools and control processes. These systems are "Windows PCs" in name only. They're (usually) air-gapped, and one of the few potential vectors for infections are the USB drives. They can't silicone the ports, because they need to be able to use specifically authorized USB drives to move "stuff" around... like design files, or machine setting updates. Plus, these systems often have keyboards and mice and button pads and joysticks that are USB connected.

    We've spent the last several years working with a major industrial security vendor to build and refine a complex security system for USB devices in such settings. It fills a real need.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Pavel_APavel_A Member Posts: 2,746

    The best scenario (if possible): the user plugs any device - it won't even power on

    Disabling USP ports or specific devices/classes is a quite common need (as Peter noted), so you can google around and find a ready solution for this. Get it right now, no development & testing time, no bluescreens.
    The type C, however, is a less familiar point. Is there a requirement specific for type C? Like, disable high-power charging from the port (without any i/o at all)?
    -- pa

  • s0ckzzs0ckzz Member Posts: 8

    @Pavel_A said:

    The best scenario (if possible): the user plugs any device - it won't even power on

    Disabling USP ports or specific devices/classes is a quite common need (as Peter noted), so you can google around and find a ready solution for this. Get it right now, no development & testing time, no bluescreens.
    The type C, however, is a less familiar point. Is there a requirement specific for type C? Like, disable high-power charging from the port (without any i/o at all)?
    -- pa

    Yeah, it's a requirement of my client... Anyway, for USB ports do you have any link for the examples? Maybe it can be similar for USB Type-C...

  • Pavel_APavel_A Member Posts: 2,746
    edited November 13

    There are examples of hub access from usermode, based IIRC on some Intel's example from WinXP times.
    Some classes of devices can be disabled by Windows group policy - no coding needed at all.
    For useful start in USB hub filtering, see here: https://github.com/freedesktop/spice-usbdk
    Sorry I cannot share code from commercial projects. In the linuxy opensourcey world, when they make anything, they put it on GitHub and write a dozen blogs and tweets. Not so in Windows.
    Again, consider a ready product. Reinventing a wheel is not cool. If the UI needs customization, maybe they can do that.
    Unless, there's some special new type C quirk - as type C connector is more than USB.

    -- pa

  • MBond2MBond2 Member Posts: 210

    I think I must have missed something, but is this all devices on a particular port, or particular devices (inclusively or exclusively) on any port?

    the viability of any solution on any os depends to a great extent on these answers i think

  • s0ckzzs0ckzz Member Posts: 8

    @Pavel_A said:
    There are examples of hub access from usermode, based IIRC on some Intel's example from WinXP times.
    Some classes of devices can be disabled by Windows group policy - no coding needed at all.
    For useful start in USB hub filtering, see here: https://github.com/freedesktop/spice-usbdk
    Sorry I cannot share code from commercial projects. In the linuxy opensourcey world, when they make anything, they put it on GitHub and write a dozen blogs and tweets. Not so in Windows.
    Again, consider a ready product. Reinventing a wheel is not cool. If the UI needs customization, maybe they can do that.
    Unless, there's some special new type C quirk - as type C connector is more than USB.

    -- pa

    Thank you, that link will help a lot! What ready product would you recommend?

  • s0ckzzs0ckzz Member Posts: 8

    @MBond2 said:
    I think I must have missed something, but is this all devices on a particular port, or particular devices (inclusively or exclusively) on any port?

    the viability of any solution on any os depends to a great extent on these answers i think

    The requirement is to disable an specific physical port so, any device will be attached.

  • ThatsBerkanThatsBerkan Member Posts: 17
    edited November 14

    I believe the easiest way (althought extremely not recommended), would be to hook the PnP major dispatch of the USB Hub Driver and return an invalid NTSTATUS whenever it is an arrival of a (No idea how you're going to detect this) USB-C device.

    This will most likely display a warning icon in the Device Manager for the USB Hub Driver.

    Post edited by ThatsBerkan on
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,158

    would be to hook the PnP major dispatch of the USB Hub Driver

    That is not a good idea, or anything remotely like a supported approach.

    We have filter drivers in Windows for a reason.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Pavel_APavel_A Member Posts: 2,746

    What ready product would you recommend?

    Most of so called "endpoint security" products have some kind of USB control.
    I haven't used this stuff recently (concur with Mr. Roberts on products that exist to tamper with normal operation of my Windows system)
    If you find the freedesktop link interesting, the maintainers of this thing are on this forum. They may be able to help you.
    -- pa

  • adriano_lemosadriano_lemos Member Posts: 2

    @Peter_Viscarola_(OSR) said:

    would be to hook the PnP major dispatch of the USB Hub Driver

    That is not a good idea, or anything remotely like a supported approach.

    We have filter drivers in Windows for a reason.

    Peter

    Hi, please forgive my ignorance, but I have the same problem which I intend to approach by developing a USB Bus Filter Driver (UpperFilter) to change the DEVICE_RELATIONS list after the Bus responded to the PNP_MN_QUERY_DEVICE_RELATIONS, whenever a new device is plugged in an arbitrary USB port. The intention is to "soft disable" that port by preventing any new device connecting to it from being enumerated.

    Is it possible to write this as a KMDF USB Hub Filter Driver (maybe modifying one of the sample drivers from Microsoft's Github)?

    Thanks in advance and, again, forgive me if I misunderstood some basic concept for I'm new to this kind of endeavor.

    Adriano Lemos.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,375
    via Email
    Yes it is possible to write a bus filter driver for usb. It is a lot of
    work. KMDF does not support bus filter drivers, but with a bit of effort
    you can use kmdf to do most of the work and then escape out of kmdf to do
    the rest using WDM.

    Mark Roddy
  • adriano_lemosadriano_lemos Member Posts: 2

    Thanks @Mark_Roddy. Much appreciated the information.
    Can you (or any member) point me to some repository or post with sample code showing how I could accomplish this task? That could save me an awful lot of time.

    Thanks again,
    Adriano Lemos.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE