linux-kernel - Re: [PATCH] usb: quirks: Add quirk to prefer vendor-specific configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025041129-retired-grading-1de9@gregkh>
Date: Fri, 11 Apr 2025 07:47:46 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: ivanhu <ivan.hu@...onical.com>
Cc: krzysztof.kozlowski@...aro.org, limiao@...inos.cn,
	wangyuli@...ontech.com, jinxiaobo@...ontech.com,
	huanglei@...inos.cn, mathias.nyman@...ux.intel.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: quirks: Add quirk to prefer vendor-specific
 configuration

On Fri, Apr 11, 2025 at 01:25:23PM +0800, ivanhu wrote:
> On 2025/4/10 14:58, Greg KH wrote:
> > On Thu, Apr 10, 2025 at 10:46:26AM +0800, Ivan Hu wrote:
> > > Some USB devices with multiple configurations expose a vendor-specific
> > > interface class that should be preferred by default. However, the generic
> > > usb_choose_configuration() logic selects the first configuration whose
> > > first interface uses a non-vendor-specific class, which can lead to
> > > incomplete or limited functionality.
> > > 
> > > Introduce a new quirk, USB_QUIRK_CHOOSE_VENDOR_SPEC_CFG, which
> > > instructs the USB core to prefer a configuration that contains a
> > > vendor-specific interface class when multiple configurations are present.
> > > 
> > > Apply this quirk to the ASIX AX88179 USB Ethernet adapter
> > > (0x0b95:0x1790), which requires selecting its vendor-specific
> > > configuration for full functionality, instead of falling back to
> > > cdc_ncm.
> > 
> > Shouldn't this be done in userspace instead?  And how does other
> > operating systems handle this, the "first" configuration is usually the
> > default for them as well, do they have some built-in quirk to handle
> > this or do they rely on a vendor-provided driver?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Hi Greg,
> 
> Thanks for the feedback.
> 
> In this case, the device advertises three configuration descriptors. The first is vendor-specific, the second is CDC-NCM, and the third is CDC-Ether:
> 
> Device Descriptor:
>   idVendor           0x0b95 ASIX Electronics Corp.
>   idProduct          0x1790 AX88179 Gigabit Ethernet
>   bNumConfigurations      3
> 
> Configuration 1:
>   Interface 0:
>     bInterfaceClass       255 Vendor Specific Class
> 
> Configuration 2:
>   Interface 0:
>     bInterfaceClass         2 Communications
>     bInterfaceSubClass     13 (CDC-NCM)
> 
> Configuration 3:
>   Interface 0:
>     bInterfaceClass         2 Communications
>     bInterfaceSubClass      6 (CDC-Ether)
> 
> In drivers/usb/core/generic.c, the logic currently prefers the first configuration whose first interface is non-vendor-specific,
> based on the assumption that Linux is more likely to have a generic class driver than a vendor-specific one:
> 		/* From the remaining configs, choose the first one whose
> 		 * first interface is for a non-vendor-specific class.
> 		 * Reason: Linux is more likely to have a class driver
> 		 * than a vendor-specific driver. */
> This results in the CDC-NCM configuration being selected by default, even though the kernel already supports the vendor-specific driver ax88179_178a,
> which provides the correct and full functionality.
> 
> Of course, this could be handled in userspace,

Great!  Then handle it there.

> but due to security restrictions on certain systems, such as Ubuntu
> Core, modifying configuration selection in userspace becomes
> significantly more complex and less straightforward.

That's a design decision you made, don't force the kernel to do
something that you can do in userspace just because you made a foolish
decision in your userspace design patterns.

And really, how does your userspace restrictions keep you from doing
this in userspace?  What exactly prevents this?

> And although I don’t have insight into the exact design in Windows, but during testing on a standard Windows install, the device is correctly initialized with the vendor driver without any additional configuration or modification.

Watch what happens at device insertion on the bus to see how it decides
which configuration to pick.  Is Linux's logic different somehow?  It's
odd that only now would something like this start showing up.

> Given that this quirk is device-specific and not a general change in
> policy, the proposed quirk simply allows the kernel to prefer the
> correct vendor-specific configuration when it's known to be required.

This is a policy change of "if you can do it in userspace, you should.

thanks,

greg k-h