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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5413aa3b-92ba-4367-b720-2fa4161638b5@rowland.harvard.edu>
Date: Wed, 17 Jul 2024 09:44:56 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Hongyu Xie <xy521521@...il.com>
Cc: oneukum@...e.com, gregkh@...uxfoundation.org, brauner@...nel.org,
	jlayton@...nel.org, jack@...e.cz, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, xiehongyu1@...inos.cn
Subject: Re: [PATCH next] usb: usbfs: Add reset_resume for usbfs

On Wed, Jul 17, 2024 at 11:13:39AM +0800, Hongyu Xie wrote:
> From: Hongyu Xie <xiehongyu1@...inos.cn>
> 
> 
> 
> On 2024/7/17 10:05, Alan Stern wrote:
> > I'm ignoring most of what you asked Oliver to focus on just one thing:
> > 
> > On Wed, Jul 17, 2024 at 09:43:38AM +0800, Hongyu Xie wrote:
> > > Even before usbfs->reset_resume is called (if there is one), the USB device
> > > has already been reset and in a good state.
> > 
> > You are wrong to think that being reset means the device is in a good
> > state.
> > 
> > The userspace driver may have very carefully put the device into some
> > non-default state with special settings.  All those settings will be
> > lost when the device gets reset, and they will have to be reloaded
> > before the device can function properly.  But the userspace driver won't
> > even know this has happened unless the kernel tells it somehow.
> > 
> I was looking the whole thing from kernel's perspective. Thank you for
> pointing it out for me.
> > Oliver is pointing out that the kernel has to tell the userspace driver
> > that all the settings have been lost, so the driver will know it needs
> > to load them back into the device.  Currently we have no way to send
> > this information to the driver.  That's why usbfs doesn't have a
> > reset_resume callback now.
> But I still think that there's no need to rebind for a USB device that was
> using usbfs. Because rebinding doesn't fix settings lost. And it looks
> strange from user-space's perspective.
> What do you think?

That's right, it should be possible to avoid rebinding.  But we can't do 
this until we have some way to tell the userspace driver that a reset 
has occurred.  Oliver's idea is to do this by returning a special error 
code for the next ioctl, and I can't think of anything better.

Alan Stern