linux-kernel - Re: [PATCH next] usb: usbfs: Add reset

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]

Message-ID: <9ef72886-13b8-46cf-a0aa-54dad36102e9@rowland.harvard.edu>
Date: Thu, 11 Jul 2024 10:41:50 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: Hongyu Xie <xiehongyu1@...inos.cn>, gregkh@...uxfoundation.org,
	brauner@...nel.org, jlayton@...nel.org, jack@...e.cz,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH next] usb: usbfs: Add reset_resume for usbfs

On Thu, Jul 11, 2024 at 10:59:56AM +0200, Oliver Neukum wrote:
> 
> 
> On 11.07.24 10:43, Hongyu Xie wrote:
> > During hibernation, usb_resume_interface will set needs_binding to 1 if
> > the usb_driver has no reset_resume implimentation. The USB interface
> > will be rebind after usb_resume_complete.
> > 
> > Normally, that's fine. But if a USB interface has a matched kernel
> > driver, and a userspace driver or application is using this USB
> > interface through usbfs during hibernation, usbfs will be
> > detatched with the USB interface after resume. And this USB interface
> > will be bind with a kernel driver instead of usbfs.
> > 
> > So add reset_resume to fix this.
> 
> The device has lost all settings, yet we continue like nothing
> changed. That strikes me as a very bad idea. If a device has undergone
> a reset user space has not requested, we need to return an error upon
> the next interaction.
> 
> I am sorry, but this implementation has some fundamental issues.

Agreed, but the solution is pretty simple.  Because the device was 
suspended, the userspace driver must have enabled suspend via the 
USBDEVFS_ALLOW_SUSPEND ioctl.  

At that point, although the driver _could_ try to do some I/O to the 
device, the safest approach is for the driver to call the 
USBDEVFS_WAIT_FOR_RESUME or USBDEVFS_FORBID_SUSPEND ioctl.  So those two 
places are where we can return a specific error code to indicate that 
the device was reset while resuming.

Alan Stern