linux-kernel - Re:Re: Re: [PATCH] USB: add usbfs ioctl to get specific superspeedplus rates

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 4 Aug 2023 12:16:19 +0800 (CST)
From:   "Dingyan Li" <18500469033@....com>
To:     "Alan Stern" <stern@...land.harvard.edu>
Cc:     "Hans de Goede" <hdegoede@...hat.com>,
        "Greg KH" <gregkh@...uxfoundation.org>,
        "Xiaofan Chen" <xiaofanc@...il.com>,
        "Oliver Neukum" <oneukum@...e.com>,
        "Tormod Volden" <lists.tormod@...il.com>,
        sebastian.reichel@...labora.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re:Re: Re: [PATCH] USB: add usbfs ioctl to get specific
 superspeedplus rates

At 2023-08-04 01:56:03, "Alan Stern" <stern@...land.harvard.edu> wrote:
>On Fri, Aug 04, 2023 at 12:06:15AM +0800, Dingyan Li wrote:
>> So after usb_device_speed is extended with Gen2x1, Gen1x2 and Gen2x2,
>> it feels that enum usb_ssp_rate becomes useless. Is it okay to just delete it?
>> I'm asking this since it is also used in several other source files so the fix may
>> not be as trivial as it looks.
>
>As long as the file is being used by other source files, don't delete 
>it.  If you want to fix up all those other places and then delete the 
>file, that's fine.  But of course, it would have to be a separate set of 
>patches.
>
>It will also be necessary to audit the places in the kernel that 
>currently use usb_device_speed.  Some of them may need to be extended to 
>handle the new entries properly.  (Including, obviously, the parts of 
>the code that store the device's speed in the first place.)
>

>Alan Stern

Another issue is that USB_SPEED_SUPER_PLUS has been widely used in
so many files to execute conditional banches. Once we extend and store device's
speed with new values in the first place, we might need to check all places where
USB_SPEED_SUPER_PLUS is used in case of any regression.

I think maybe we can try to remove the dependency on enum usb_device_speed
in usbfs and define a separate set of speed values similar to previous design
at https://www.spinics.net/lists/linux-usb/msg157709.html
By this way, in usbfs we get more freedom to determine how to explain
usb_device_speed and usb_ssp_rate, without the risk of breaking anything
elsewhere.

For example, define an USBDEVFS_SPEED_SUPER_PLUS to indicate
USB_SPEED_SUPER_PLUS with ssp rates GEN_UNKNOWN, GEN_2x1 and
GEN_1x2. They all stand for 10Gbps and we don't need to tell one from
another, similar to how it works in sysfs. Then define an
USBDEVFS_SPEED_SUPER_PLUS_BY2(maybe there is a more proper name)
to indicate USB_SPEED_SUPER_PLUS with ssp rate GEN_2x2, which stands
for 20Gbps.

Regards,
Dingyan