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: <4b7888b7-8848-4374-b532-f65cefd40e56@suse.com>
Date: Mon, 15 Jul 2024 10:40:44 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Hongyu Xie <xy521521@...il.com>, stern@...land.harvard.edu
Cc: gregkh@...uxfoundation.org, oneukum@...e.com, 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 15.07.24 03:13, Hongyu Xie wrote:
> From: Hongyu Xie <xiehongyu1@...inos.cn>

>>> When will "a reset user space has not requested" happen if there is a
>>> reset_resume in usbfs?

The literal answer to your question is: during resumption
of the device or when power was restored to it.
Before reset_resume() is called.

>> That's what a reset-resume is: a reset that occurs when the device is
>> resumed, rather than when the driver has requested a reset.
> Right now this reset_resume did nothing, it's just an empty function to prevent rebind after resume.
> Maybe I should filter out usbfs in usb_resume_interface when setting needs_binding to 1?

Strictly speaking this is true. But it overlooks that at that
point something has already been done to the device. Either it has
literally been reset by instructing the hub it is connected to
to reset a port or by interrupting the power supply.

The important point in terms of semantics is that the device state
has been lost. And it has been potentially lost within user space
knowing about it.
There is an inevitable race between a suspend/resume cycle and the
next usbfs operation. Therefore After a suspend()/reset_resume()
cycle the next usbfs operation must not be executed and an error
returned to user space.

At present that error is ENODEV.

	Regards
		Oliver