linux-kernel - Re: [PATCH v2] char: xillybus: Check endpoint type before allocing

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: <628BBEEB.9010306@gmail.com>
Date:   Mon, 23 May 2022 20:05:47 +0300
From:   Eli Billauer <eli.billauer@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     Zheyu Ma <zheyuma97@...il.com>, arnd@...db.de,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] char: xillybus: Check endpoint type before allocing

On 23/05/22 19:06, Greg KH wrote:
> If the device does not have the EXACT USB endpoints that you are
> expecting (size, address, direction, type, etc.) at probe time reject
> the device.
>    
This is probably a good time to add some information about XillyUSB.

All XillyUSB devices have EP 1 IN and EP 1 OUT as bulk endpoints.

On top of that, they *may* have up to 14 additional bulk OUT endpoints, 
having the addresses EP 2 OUT to EP 15 OUT. The population of endpoint 
addresses is not necessarily continuous. Any set of OUT endpoint 
addresses is allowed. The driver doesn't know which of these endpoints 
are available initially.

Rather, it works like this: The driver uses the EP 1 IN and OUT 
endpoints to query the device for a data structure, which contains 
information on the device's communication channels. The driver sets up 
device files accordingly, and it also gets informed on which bulk OUT 
endpoints are present.

For what it's worth, I think it's fairly safe to assume that if a device 
returns a legal data structure (which passes a CRC test), it's a 
XillyUSB device. Either way, it's impossible to verify that all of the 
device's bulk OUT endpoints are correct before obtaining the data 
structure from the device. The fact that each device has a different set 
of communication channels, and that the driver learns about them in 
run-time is the whole trick with Xillybus and XillyUSB.

And just in case you wonder why there's only one bulk IN endpoint: All 
inbound communication, control as well as data, is multiplexed into this 
single endpoint. That's in order to allow the device better control on 
which communication channel is serviced at any time, with a few 
microseconds' granularity. The same trick is unfortunately infeasible in 
the other direction.

I don't have any particular view on how the device should be validated, 
but I thought this information would be helpful.

Thanks,
    Eli