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: <3073c8ce-1923-4816-a442-41b4cc333af9@suse.com>
Date: Tue, 16 Jul 2024 14:44:50 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Alan Stern <stern@...land.harvard.edu>, 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 15.07.24 16:22, Alan Stern wrote:
> On Mon, Jul 15, 2024 at 10:53:14AM +0200, Oliver Neukum wrote:
>>
>>
>> On 11.07.24 16:41, Alan Stern wrote:

>>> 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.
>>
>> The whole system could have been suspended, in particularly to S4.
> 
> You are right.  I was thinking of runtime suspend, not system suspend.
> My mistake.

This is at the intersection of several scenarios. That is a good part of
what makes this difficult.
In principal I think we could get away with checking for a flag to be set
at reset_resume() before each operation. Elegant this is not. Yet, it seems
to me like the race necessarily exists and is unsolvable in user space.

Furthermore in the long run, if we want to use D3cold in runtime power
management, it looks to me like we would want a second permission ioctl
for that.

	Regards
		Oliver