linux-kernel - Re: [PATCH v2] usbip: convert to use faux

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: <9be8b1dc-9af2-4135-9a0f-db2eb7d10f06@linuxfoundation.org>
Date: Thu, 10 Jul 2025 14:33:42 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Alan Stern <stern@...land.harvard.edu>,
 Greg KH <gregkh@...uxfoundation.org>, Zongmin Zhou <min_halo@....com>
Cc: shuah@...nel.org, valentina.manea.m@...il.com, i@...ithal.me,
 linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
 zhouzongmin@...inos.cn, Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2] usbip: convert to use faux_device

On 7/10/25 08:06, Alan Stern wrote:
> On Wed, Jul 09, 2025 at 03:57:35PM -0600, Shuah Khan wrote:
>> On 7/9/25 15:49, Shuah Khan wrote:
>>> Right. We have a few too many moving pieces here:
>>>
>>> usbipd (user-space)
>>> vhci_hcd and the usb devices it creates
>>>
>>> usbip_host, stub driver that proxies between the device
>>> on the server and vhci_client.
>>>
>>> PM can be complex and it has to do lot more than it currently
>>> does on both server and client end to support seamlessly.
>>>
>>> The current suspend took the approach of refusing suspend
>>> which doesn't work since usb devices underneath hang in
>>> usb_dev_resume(). Looks like this usb device is treated like
>>> a real device bu usb core. Is there a way to have usb core
>>> PM (suspend and resume) handle them as virtual? Would it
>>> help to use "supports_autosuspend" to disable suspend and
>>> resume?
>>
>> Would it work if usb_disable_autosuspend() on the devices
>> that hang off its vitual bus?
> 
> You have to consider PM on both the host and client.  And you have to
> consider both runtime PM and system PM (that is, suspend to RAM,
> hibernate, etc.).

This would be as a fix for the existing suspend hang issue.

> 
> On the server, any sort of suspend will interrupt the connection.
> usb_disable_autosuspend() will prevent runtime suspends, but you
> shouldn't try to prevent system suspends.  Instead, the usbip driver on
> the server should have its suspend routine close the connection to the
> client (rather as if the server's user had unplugged the device).
> 
> On the client, you've got a choice for how to handle runtime PM.  You
> can leave it enabled, and when the client decides to suspend the device,
> tell the server's driver.  The server driver can then attempt to do a
> runtime suspend on the physical device.  (You might need to add a new
> type of message to the USBIP protocol to accomplish this; I don't know
> the details.)  Alternatively, you can forbid runtime suspend on the
> client entirely, although it would be nice if you could avoid this.
> 
> System PM on the client can be handled more less the same as runtime PM.

Correct. This has to be a complete solution that syncs up server and client
side. I am going to look into implementing this - it might be possible to
do this in user-space. Either way this will require changes to the protocol
very likely.

Greg, Zongmin Zhou, let's hold off on this conversion yo faux bus for now.
I will spend time looking at if we can find PM solution that works end to end
for server and client.

thanks,
-- Shuah