linux-kernel - Re: [PATCH 0/3] usb: gadget: 9pfs transport

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: <0aba51a8be0fb165b44ec956bec7a9698a9518a2.camel@pengutronix.de>
Date: Tue, 16 Jan 2024 16:51:41 +0100
From: Jan Lübbe <jlu@...gutronix.de>
To: Dominique Martinet <asmadeus@...ewreck.org>, Michael Grzeschik
	 <m.grzeschik@...gutronix.de>
Cc: Latchesar Ionkov <lucho@...kov.net>, linux-usb@...r.kernel.org, Jonathan
 Corbet <corbet@....net>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 v9fs@...ts.linux.dev,  Christian Schoenebeck <linux_oss@...debyte.com>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel@...gutronix.de,  Eric Van Hensbergen <ericvh@...nel.org>
Subject: Re: [PATCH 0/3] usb: gadget: 9pfs transport

On Tue, 2024-01-16 at 20:45 +0900, Dominique Martinet wrote:
> Michael Grzeschik wrote on Tue, Jan 16, 2024 at 02:49:40AM +0100:
> > This series is adding support to mount 9pfs exported filesystems via the
> > usb gadget interface. It also includes tools and descriptions on how to
> > translate an tcp 9pfs and use it via the usb interface.
> 
> So I didn't have time to look at everything through, just want to make
> sure, this series allows sharing data from an usb gadget (e.g. some
> device with storage) over 9p as an alternative to things like MTP ?

It's the other way around. :) The USB host exports a filesystem, while the
gadget on the USB device side makes it mountable. Our main use-case is to use it
as an alternative to NFS root booting during the development of embedded Linux
devices. NFS root works in many cases, but has some downsides, which make it
cumbersome to use in more and more cases.

NFS root needs correctly configured Ethernet interfaces on both the development
host and the target device. On the target, this can interfere with the network
configuration that is used for the normal device operation (DHCP client, ..).
For the host, configuring a NFS (and perhaps DHCP) server can be an obstacle.

For target devices which don't have a real Ethernet interface, NFS root would
also work with the USB Ethernet gadget, but this increases the complexity
further.

As many embedded boards have a USB device port anyway, which is used during
development for uploading the boot-loader and to flash filesystem images (ie.
via the fastboot protocol), we want to just reuse that single data cable to
allow access to the root filesystem as well. 

Compared to flashing images, using a network filesystem like NFS and 9P reduces
the time between compiling on the host and running the binary on the target, as
no flash and reboot cycle is needed. That can get rid of many minutes of waiting
over a day. :)

> I don't quite understand what the forwarder and diod have to do with
> this; you're emulating a fake usb device with the forwarder that just
> transmits requests to diod as backend implementation?
> But 'usb.core.find(idVendor=0x1D6B, idProduct=0x0109)' looks like it's
> searching for a real device not creating one, so that doesn't seem to
> match up...

diod (9pfs server) and the forwarder are on the development host, where the root
filesystem is actually stored. The gadget is initialized during boot (or later)
on the embedded board. Then the forwarder will find it on the USB bus and start
forwarding requests.

It may seem a bit unusual that in this case the requests come from the device
and are handled by the host. The reason is that USB device ports are normally
not available on PCs, so a connection in the other direction would not work.

In the future, the functionality of the forwarder could be integrated into the
9pfs server. Alternatively, an improved forwarder could also react to udev
events of gadgets showing up and forward them to different 9PFS server over the
network (when you have multiple target devices connected to one USB host).

Perhaps, the inverse setup (9PFS server on the USB gadget side, mounted on a PC)
also would be useful in the future and could share some of this code. Then,
you'd have an alternative to MTP.

> If you have any background information on where you're coming from and
> where this is headed it'd be great to include in the cover letter.

Yes. Probably also in Documentation/.

Thanks,
Jan