linux-kernel - RE: [PATCH] usb: hub add filter for device with specific VID&PID

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <DB8PR04MB6826763082AF84812426CC53F1830@DB8PR04MB6826.eurprd04.prod.outlook.com>
Date:   Sun, 29 Sep 2019 02:35:05 +0000
From:   Ran Wang <ran.wang_1@....com>
To:     Alan Stern <stern@...land.harvard.edu>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Mathias Payer <mathias.payer@...elwelt.net>,
        Dennis Wassenberg <dennis.wassenberg@...unet.com>,
        "open list:USB SUBSYSTEM" <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: hub add filter for device with specific VID&PID

Hi Alan,

On Saturday, September 28, 2019 01:08, Alan Stern wrote:
> 
> On Tue, 24 Sep 2019, Ran Wang wrote:
> 
> > Hi Greg,
> >
> > On Monday, September 23, 2019 19:07, Greg Kroah-Hartman wrote:
> > >
> > > On Mon, Sep 23, 2019 at 06:51:02PM +0800, Ran Wang wrote:
> > > > USB 2.0 Embedded Host PET Automated Test (CH6) 6.7.23 A-UUT
> > > > "Unsupported Device" Message require to stop enumerating device
> > > > with VID=0x1a0a PID=0x0201 and pop message to declare this device
> > > > is not
> > > supported.
> > >
> > > Why is this a requirement?
> >
> > This comes from <USB On-The-Go and Embedded Host Automated Compliance
> > Plan for the On-The-Go& Embedded Host Supplement Revision2.0>
> 
> How much do we care about our support for USB OTG?  Isn't it dying off?

As I know, some vendors still want to pass this Embedded Host compliance test
to make sure their product's quality. And above test case is included.

> > Below is related description I quote from it:
> > 6.7.23 A-UUT "Unsupported Device" Message
> > Purpose: This test verifies that an A-UUT produces a device non-supported
> error message
> > 	when a device it doesn't recognize, and does not support HNP, connects
> to it.
> > Applies to: All Targeted Hosts
> > Description: Get VBUS turned on, and connect to the A-UUT. Get enumerated
> and respond
> > 	as an unknown device not supporting HNP. Check that a suitable error
> message is generated.
> > Pass Criteria: Message "Unsupported Device"or similar is displayed on
> > UUT
> >
> > 6.7.23.1 Test Procedure
> > 1. Start with cable still attached, PET applying 10 F capacitance and 10k  pull-
> down
> >     resistance between VBUS and ground, data lines not pulled up.
> > 2. Get VBUS turned on, using the method described in Section6.7.1.
> > 3. Wait for almost TB_SVLD_BCON max (1s - 0.1s = 0.9s) from VBUS reaching
> VOTG_SESS_VLD max.
> > 4. Connect PET using D+ pull-up.
> > 5. Allow A-UUT to enumerate PET, responding with a VID / PID combination
> not on the TPL
> >     of the UUT and also with the OTG descriptor stating that it does not support
> HNP.
> > 6. Start 30s timer when Device Descriptor is read.
> > 7. Display Message "Click OK if 'Unsupported Device' indication displayed on
> UUT".
> > 8. If operator clicks OK before 30s timer expires, then UUT passes test.
> > 9. If 30selapses first, then UUT fails test.
> > 10. PET disconnects by removing any termination on the data lines, but leaves
> a capacitance of
> >     10 F and a pull-down resistance of 10k  connected across VBUS.
> > 11. Wait 2s to allow disconnection to be detected.
> > End of Test.
> 
> In fact, the system should respond the same way to any unrecognized device
> that doesn't support HNP, right?  There's nothing special about these VID/PID
> values.

Yes, but I saw there are already some implementation in upstream kernel for this purpose,
just PID different: drivers/usb/core/otg_whitelist.h function is_targeted()

> > > And why those specific vid/pid values?  What do they refer to?
> >
> > For step 5, we got the VID / PID number from USB IF certified
> > lab(Allion.inc at Taiwang). Looks like this is a reserved ID pair and
> > will not be allocated to any vendor for their products. So it's hence used for
> this case test (like saying: you should be able to pop a not-support message for
> this reserved VID&PID).
> 
> Don't we do this already?

Yes, but in function is_stargeted(), I found it's a little be different:
Current upstream:                     VID = 0x1a0a, PID = 0x0200
Info from USB-IF certified lab: VID = 0x1a0a, PID = 0x0201

Regards,
Ran

> Alan Stern