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: <b15d0ba0-e133-4df7-8371-a701ec5005fb@kylinos.cn>
Date: Mon, 15 Jul 2024 09:13:30 +0800
From: Hongyu Xie <xy521521@...il.com>
To: stern@...land.harvard.edu,
	xy521521@...il.com
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

From: Hongyu Xie <xiehongyu1@...inos.cn>

On 2024/7/13 10:22, Alan Stern wrote:
> On Fri, Jul 12, 2024 at 11:10:57AM +0800, Hongyu Xie wrote:
>> From: Hongyu Xie <xiehongyu1@...inos.cn>
>>
>>
>>
>> On 2024/7/11 16:59, 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.
>> Sorry I don't understand your concern.
>> When will "a reset user space has not requested" happen if there is a
>> reset_resume in usbfs?
> 
> 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?
> 
> Alan Stern
> 
>>> I am sorry, but this implementation has some fundamental issues.
>>>
>>>       Regards
>>>           Oliver
>>>
>> Regards
>> Hongyu Xie

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ