On 12/02/2016 02:38 AM, fx IWATA NOBUO wrote: > Hello, > >> I am not clear on this. Is Client and server behind different >> firewalls? > > No. > The firewall is in between internet and <intranet, soho, home, etc.> > >> So the above doesn't apply to a) and it works? > > Yes. > >> What does this mean? Why is this connection from outside? > > 'usbip attach -r' tries to establish connection. That doesn't tell me much. I am looking to see in the above where are the server and client located. > >> Is this something that could be solved by opening ports in >> the firewall? > Usually, http(80) and https(443) from inside is opened for internet > Access. You can open other ports if need be and if you have access to firewall. > > >> Can we use server and client terminology which is we use in instead of >> App and Dev. > > In https://www.kernel.org/doc/readme/tools-usb-usbip-README, I couldn't > find the definition. > > Do you mean 'server' is a linux machine which has devices > or linux machine which runs server daemon? > > In existing way, they are same. Yes. Server is the system with the USB device physically attached to. > > In new way, they are not. > The linux machine which has device doesn't have server daemon. Okay this is a big change and that isn't very clear in any of the change logs. This is one of my concerns with the patch series. I want to understand how a different server (system that doesn't have the USB device physically attached) can be authorized to export devices that don't belong to it. Something about this model doesn't sound right. If I have system that sits behind a firewall, I don't want USB devices visible to anybody and everybody. I don't see anything in this series that disallows that, short of saying don't enable USB/IP. I would like to know why there is a need to change the existing server-client model. I still would like to see a concrete answer why the current model doesn't work. Doesn't making sure port 3240 isn't blocked on the firewall help? btw: could you please re-run get_maintainers - my email address in the MAINTAINERS file changed a while ago. I think your email might be outdated. thanks, -- Shuah > > I'd like to confirm the definition to answer rest of questions. > > Best Regards, > > n.iwata > // >> -----Original Message----- >> From: Shuah Khan [mailto:shuah.kh@xxxxxxxxxxx] >> Sent: Friday, December 02, 2016 9:39 AM >> To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; >> gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx >> Cc: fx MICHIMURA TADAO; Shuah Khan >> Subject: Re: [PATCH v13 00/10] usbip: exporting devices >> >> On 11/23/2016 10:01 PM, fx IWATA NOBUO wrote: >>> Hello, >>> >> Looks like you removed the text. Let's go back to the goals. >> Can we use server and client terminology which is we use in instead of App >> and Dev. It makes lot easier to understand. >> >> https://www.kernel.org/doc/readme/tools-usb-usbip-README >> >>>> 1. Goal >> >>>> 1-1) To give flexibility to direction of connection Using USB/IP in >>>> internet, there can be two cases. >>>> a) an application is inside firewall and devices are outside. >> >> This is the case Client is behind firewall and server is outside the >> firewall. >> >>>> b) devices are inside firewall and an application is inside. >> >> I am not clear on this. Is Client and server behind different firewalls? >> >>>> In case-a, import works because the connection is from inside. >> >>> EXISTING) >>> APP# usbip attach -----------(passed)--------> DEV# usbipd >>> DEV# usbipd (blocked)|| <--------- APP# usbip attach >> >> So the above doesn't apply to a) and it works? >> >>>> In case-b, import doesn't works because the connection is from outside. >> >> What does this mean? Why is this connection from outside? >> >>>> Connection from device side is needed. This patch set adds the >>>> direction of connection establishment. >> >> Is this something that could be solved by opening ports in the firewall? >> >> >>>> Can you elaborate on the use-case a bit more? What does it mean to >>>> "Connection from device side is needed"? >>> >>> I'd like to update ending part of use case as following. >>> --- >>> Firewall, proxy, or router in front of internet usually blocks >>> connections from internet regarding all TCP ports. They opens some >>> ports, usually HTTP(80) and HTTPS(443), for connection from inside. >>> In combination with WebSocket proxy, USB/IP can establish connection >>> from inside of the firewall. >>> >>> Enterprise/SOHO/Home Firewall/Proxy/Router Internet >>> >>> EXISTING) >>> APP# usbip attach -----------(passed)--------> DEV# usbipd >>> DEV# usbipd (blocked)|| <--------- APP# usbip attach >>> >>> NEW) >>> DEV# usbip connect ----------(passed)--------> DEV# usbipa >>> APP# usbipa (blocked)|| <--------- APP# usbip connect >>> >>> Attach operation can invite devices in internet but cannot invite >>> devices from internet. On the other hand, connect operation can >>> dedicate devices to internet but cannot dedicate devices in internet. >> >> The above isn't very clear. Do you mean to say, client can find devices >> exported by a server? When you say Internet how many servers are we looking >> at? Random servers or known servers? >> >> Current USB/IP use-cases are: >> >> - Server could export USB devices to virtual machines running on it. >> Access is confined and limited to that one system. >> - Server could export USB devices and clients as long as no firewalls >> in between. >> >> In the above two models, user has permissions to use server and client. >> In this new proposed model, how does this work? Who sets up the server to >> export or push exports to clients. How does server know which clients to >> push exports to? >> >> With a feature like this, it is important to understand the use-cases in >> detail. >> >> thanks, >> -- Shuah >> >>> --- >>> >>>> I would like to see server side and client side operations clearly. >>>> It would help me understand the use-case you are trying to add. >>> >>> It's shown in README and manual page added by patch 9/10 as below. >>> >>> app:# insmod usbip-core.ko >>> app:# insmod vhci-hcd.ko >>> >>> app:# usbipa -D >>> - Start usbip daemon. >>> >>> dev:# (Physically attach your USB device.) >>> >>> dev:# insmod usbip-core.ko >>> dev:# insmod usbip-host.ko >>> >>> dev:# usbip list -l >>> - List driver assignments for USB devices and their busid. >>> >>> dev:# usbip connect --remote <host> --busid <busid> >>> - Bind usbip-host.ko to the device with <busid>. >>> - The USB device of <busid> is connected to remote host! >>> >>> dev:# usbip disconnect --remote <host> --busid <busid> >>> - The USB device with <busid> is disconnected from remote host. >>> - Unbind usbip-host.ko from the device. >>> >>>> I do have some concerns about security on client side. User sits on >>>> the client side and it should be a pull from client side as opposed >>>> to push from server side. >>> >>> Connection level consideration is described in "5. Security >>> Consideration". As you know, USB/IP already has TCP wrapper option. >>> With SSL or WebSocket(wss) tunneling proxy, client authentication can >>> be applied using the proxies. >>> >>> I didn't write device level consideration. It's same as local device >>> plug-and-play. I will add description below in cover letter and README. >>> >>> --- >>> Udev rules can allow only known devices. To identify a device is >>> remote, the local bus-id (KERNEL parameter in the rule) will be found >>> the last in column of /sys/devices/platform/vhci_hcd/status[.N]. When >>> device is found, the port number in USB/IP can be found in the first >>> column of the matched line. The udev can finish the connection using >>> detach operation with the port number. >>> --- >>> >>>> It sounds like this patch series adds push from server side. >>> >>> Yes. >>> But it's only the initiation request and response. >>> URBs direction is just same as before. Applications send submit and >>> unlink, devices process them. >>> >>> Your comment is at goal #1. I'm also considering goal #2. >>> >>> Thanks for reviewing, >>> >>> nobuo.iwata >>> // >>>> -----Original Message----- >>>> From: Shuah Khan [mailto:shuah.kh@xxxxxxxxxxx] >>>> Sent: Thursday, November 24, 2016 1:43 AM >>>> To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; >>>> gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx >>>> Cc: fx MICHIMURA TADAO; Shuah Khan; Shuah Khan >>>> Subject: Re: [PATCH v13 00/10] usbip: exporting devices >>>> >>>> On 11/21/2016 11:48 PM, Nobuo Iwata wrote: >>>>> Dear all, >>>>> >>>>> This series of patches adds exporting device operation to USB/IP. >>>>> >>>>> NOTE: >>>>> This patch set modifies only userspace codes in tools/usb/usbip. >>>>> >>>>> 1. Goal >>>>> >>>>> 1-1) To give flexibility to direction of connection Using USB/IP in >>>>> internet, there can be two cases. >>>>> a) an application is inside firewall and devices are outside. >>>>> b) devices are inside firewall and an application is inside. >>>>> In case-a, import works because the connection is from inside. >>>>> In case-b, import doesn't works because the connection is from outside. >>>>> Connection from device side is needed. This patch set adds the >>>>> direction of connection establishment. >>>>> >>>> >>>> Can you elaborate on the use-case a bit more? What does it mean to >>>> "Connection from device side is needed"? >>>> >>>> I would like to see server side and client side operations clearly. >>>> It would help me understand the use-case you are trying to add. >>>> >>>> I do have some concerns about security on client side. User sits on >>>> the client side and it should be a pull from client side as opposed >>>> to push from server side. >>>> >>>> It sounds like this patch series adds push from server side. >>>> >>>> thanks, >>>> -- Shuah >>>> >>>>> NOTE: >>>>> Directions of URBs requests and responses are not changed. Only >>>>> direction of connection establishment initiated with usbip command >>>>> is added to exsiting one. >>>>> >>>>> 1-2) To improve usability of operations When two Linux machines are >>>>> in a small distance, it's OK to bind (makes >>>>> importable) at device side machine and attach (import) at >>>>> application side. >>>>> If application is as cloud service or in blade server, it's not >>>>> practical to attach from application side. It's useful to connect >>>>> (export) from device side. This patch set adds the new operation to >>>>> connect from device side. >>>>> >>>>> 2. What's 'exporting' device >>>>> >>>>> Exporting devices is not new. The request and response PDU have >>>>> already been defined in tools/usbip/usbip/src/usbip_network.h. >>>>> #/* Export a USB device to a remote host. */ >>>>> #define OP_EXPORT 0x06 >>>>> #define OP_REQ_EXPORT (OP_REQUEST | OP_EXPORT) >>>>> #define OP_REP_EXPORT (OP_REPLY | OP_EXPORT) >>>>> # struct op_export_request >>>>> # struct op_export_reply >>>>> #/* un-Export a USB device from a remote host. */ >>>>> #define OP_UNEXPORT 0x07 >>>>> #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT) >>>>> #define OP_REP_UNEXPORT (OP_REPLY | OP_UNEXPORT) >>>>> # struct op_unexport_request >>>>> # struct op_unexport_reply >>>>> >>>>> But they have not been used yet. This series adds new operations: >>>>> 'connect' and 'disconnect' using these PDUs. >>>>> >>>>> EXISTING) - invites devices from application(vhci)-side >>>>> +------+ >>>> +------------------+ >>>>> device--+ STUB | | application/VHCI >> | >>>>> +------+ >>>> +------------------+ >>>>> 1) usbipd ... start daemon >>>>> = = = >>>>> 2) usbip list --local >>>>> 3) usbip bind >>>>> <--- list bound devices --- 4) usbip list >> --remote >>>>> <--- import a device ------ 5) usbip attach >>>>> = = = >>>>> X disconnected 6) usbip detach >>>>> 7) usbip unbind >>>>> >>>>> NEW) - dedicates devices from device(stb)-side >>>>> +------+ >>>> +------------------+ >>>>> device--+ STUB | | application/VHCI >> | >>>>> +------+ >>>> +------------------+ >>>>> 1) usbipa ... start >>>>> daemon = = = >>>>> 2) usbip list --local >>>>> 3) usbip connect --- export a device ------> >>>>> = = = >>>>> 4) usbip disconnect --- un-export a device ---> >>>>> >>>>> Bind and unbind are done in connect and disconnect internally. >>>>> >>>>> 3. The use cases >>>>> >>>>> EXISTING) >>>>> >>>>> In existing way, computers in small distance, having same user >>>>> account, can be easily managed by a same user. Bind in local machine >>>>> and attach in remote machine by the user. The devices can be >>>>> exporsed automatically in the local machine, for example, at strat >>>>> up. They can be attached from remote. >>>>> >>>>> When there are distributes linux nodes with USB devices in internet, >>>>> they are exposed by bind operation at start up, server behind >>>>> firewall can list and attach the devices. >>>>> Internet >>>>> Exposed +----------+ +--------+ >> +--------+ >>>>> +------+ |Linux |+ |Router, | |Service | >>>>> +|device|--|Controller||-------------------|proxy, |----|on | >>>>> |+------+ +----------+| |firewall| |Linux | >>>>> +------+ +----------+ +--------+ +--------+ >>>>> <--- attach(import) >>>>> USB/IP + WS proxy WS proxy + >> USB/IP >>>>> >>>>> NEW) >>>>> >>>>> Assuming that a server computer which runs application and VHCI is >>>>> in a server room and device side machines are small distributed >>>>> nodes outside of the server room, the operator of the server compter >>>>> is different form the distributed nodes. The server computer may be >>>>> in unattended operation. In the new way, after the daemon has been >>>>> started, device can be connected with connect command in the >>>>> distributed nodes. If the distributed nodes doesn't have user >>>>> interface, the connect command can be executed from start up procedure. >>>>> >>>>> In another senario to connect devices to a Linux based cloud service >>>>> using WebSocket proxy, it's needed to establish connection from a >>>>> device inside of firewall to a service outside. Exporting is >>>>> suitable for the senario. >>>>> >>>>> Home/SOHO/Intranet Internet >>>>> +----------+ +--------+ >> +--------+ >>>>> +------+ |Linux |+ |Router, | |Internet| >>>>> +|device|--|Controller||----|proxy, |-------------------|service | >>>>> |+------+ +----------+| |firewall| |on Linux| >>>>> +------+ +----------+ +--------+ +--------+ >>>>> connect(export) --> >>>>> USB/IP + WS proxy WS proxy + >> USB/IP >>>>> ex) >>>>> Device Service >>>>> sensors ......................................... environment >>>>> analysis cameras ......................................... >>>>> monitoring, recording ID/biometric readers >>>>> ............................ authentication >>>>> >>>>> Connection from outside firewall is usually blocked. >>>>> So existing import request sent with attach command doesn't work. >>>>> >>>>> # usbipd (blocked)|| <--------- # usbip attach >>>>> >>>>> Firewall opens some ports, usually HTTP(80) and HTTPS(443), from inside. >>>>> Then export request sent with new connect command works. >>>>> >>>>> # usbip connect -----------------------------> # usbipa >>>>> (passed) >>>>> >>>>> 4. Combination with vUDC >>>>> >>>>> New operations work with vUDC. --device option specifies vUDC mode >>>>> as well as list operaion. With stub, connect and disconnect execute >>>>> bind and unbind internally. With vUDC, they do not execute bind and >> unbind. >>>>> They are done by UDC interface. >>>>> >>>>> 5. Security consideration >>>>> >>>>> When application side daemon is not started, this patch set doesn't >>>>> affect exsiting security. >>>>> >>>>> Daemons accept following requests form network : >>>>> EXISTING) 'list --remote' and 'attach' >>>>> NEW) 'connect' and 'disconnect' >>>>> >>>>> TCP wrappers allows and/or denies network access. It is enabled when >>>>> the daemons are compiled with ./configure --with-tcp-wrappers. >>>>> >>>>> When the daemons are running with SSL or Secure WebSocket tunneling >>>>> proxy, the proxy can use client authentication with certificate files. >>>>> >>>>> 6. Mixed usage >>>>> >>>>> Both existing and new way work in same machines simultaneously. >>>>> Status of devices and ports are controlled in stub and vhci driver. >>>>> >>>>> 7. Wording >>>>> >>>>> Adding the new operation, some inconsistnecies in wording are >>>>> appeared in documentation, function name, etc. If needed, they are >> fixed. >>>>> >>>>> 'export' is used for bind and 'exported' is used for bound. They are >>>>> changed to 'make importable' and 'imported' respectively. The words >>>>> are not new. For example, in the output of port operation, 'imported >>>>> devices' is already used. >>>>> >>>>> 'client' and 'server' are switched between existing and new operation. >>>>> Sometimes they implies device-side and application-side. So, words >>>>> 'device-side' and 'application-side' are used in documentations as >>>>> needed for clarity. >>>>> >>>>> --- >>>>> Version information >>>>> >>>>> This series is divided from "USB/IP over WebSocket" patch set. >>>>> Rest of the set will be sent as another series. >>>>> >>>>> v13) >>>>> # Recreated based on linux-next 20161117. >>>>> # Updated cover letter: added goal, rewrote overview as explanation >>>>> of 'exporting' and added that this patch dosn't affect security >>>>> condition in existing usage. >>>>> # Moved protocol documentation as the last patch. >>>>> # Added explanation to each patch. >>>>> # Removed copyright from usbip_bind.c, usbip_unbind.c, >>>>> usbip_network.h and usb_list.c in which size of modification is >>>>> small and functional change is not included. >>>>> # Fixed help string about position of --parsable option. >>>>> >>>>> v12) >>>>> # Recreated based on linux-next 20161012. >>>>> # Fixed checkpatch a warning about symbolic permission. >>>>> # Fixed checkpatch warnings about traling space in a document. >>>>> >>>>> v11) >>>>> # Corrected program name of each daemon which are used in version >>>>> string, info messages and daemon name for tcp wrappers. >>>>> # Added description about tcp wrappers in security consideration of >>>>> cover letter. >>>>> # Added security consideration for existing requests in >>>>> contradistinction to new requests. >>>>> # Recreated based on linux-next 20160928. >>>>> >>>>> v10) >>>>> # Recreated based on linux-next 20160810. >>>>> >>>>> v9) >>>>> # Moved a set_nodelay() from usbipd_dev.c to usbipd.c to affect both >>>>> device side and application side daemon. >>>>> # Removed redundant blank line at the end of files. >>>>> >>>>> v8) >>>>> # Divided into smaller patches. >>>>> # Excluded low-related patches. >>>>> # Improved change log. >>>>> # Changed info level logs in usbip_ux.c to debug level logs. >>>>> # Added options to vUDC. >>>>> # Tested with vUDC. >>>>> >>>>> v7) >>>>> # Removed userspace transmission and WebSocket command/daemon. >>>>> # Fixed checkpatch errors and warnings. >>>>> >>>>> v6) >>>>> # Added __rcu annotation to a RCU pointer to clear sparse warnings. >>>>> # Corrected a copy to RCU pointer with rcu_rcu_assign_pointer(). >>>>> # Added __user annotations to arguments of read/write method. >>>>> # Added static to some functions which are not called from other files. >>>>> # Removed unnecessary EXPORT_SYMBOLs. >>>>> >>>>> v5) >>>>> # Added vendor/pruduct name conversion to port command. >>>>> # Put initial value to pool_head in name.c. >>>>> # Fixed list command exception when host option is omitted. >>>>> # Fixed exception in case gai_strerror() returns NULL. >>>>> # Fixed WebSocket connection close via proxy. >>>>> # Fixed to stop WebSocket ping-pong on connection close. >>>>> # Removed redundant usbipd daemon option. >>>>> # Removed redundant SSL code had not been deleted. >>>>> # Removed an unused local variable in WebSocket code. >>>>> # Modified C++ reserved word in names.c as same as headers. >>>>> >>>>> v4) >>>>> # Fixed regression of usbip list --remote >>>>> >>>>> v3) >>>>> # Coding style for goto err labels are fixed. >>>>> # Defined magic numbers for open_hc_device() argument. >>>>> # Corrected include .../uapi/linux/usbip_ux.h as <linux/usbip_ux.h>. >>>>> # Modified parameter notation in manuals not to use '='. >>>>> # Fixed inappropriate version definition in >>>>> tools/.../websocket/configure.ac. >>>>> # Remved unnecessary COPYING and AUTHORS fil from tools/.../websocket/. >>>>> # Added -version-info to libraries in tools/.../src. >>>>> >>>>> v2) >>>>> # Formatted patches from linux-next. >>>>> # Fixed change log word wrapping. >>>>> # Removed SSL patches. >>>>> # Fixed a bug that vendor and product names are not shown by 'usbws >>>>> list -l' because usbip_names_init() was not called in libusbip.la. >>>>> >>>>> Thank you, >>>>> >>>>> Nobuo Iwata <nobuo.iwata@xxxxxxxxxxxxxxx> // >>>>> >>>>> *** BLURB HERE *** >>>>> >>>>> Nobuo Iwata (10): >>>>> usbip: exporting devices: modifications to network header >>>>> usbip: exporting devices: modifications to host side libraries >>>>> usbip: exporting devices: new connect operation >>>>> usbip: exporting devices: new disconnect operation >>>>> usbip: exporting devices: modifications to daemon >>>>> usbip: exporting devices: modifications to attach and detach >>>>> usbip: exporting devices: new application-side daemon >>>>> usbip: exporting devices: change to usbip_list.c >>>>> usbip: exporting devices: chage to documenattion >>>>> usbip: exporting devices: modifications to protocol text >>>>> >>>>> Documentation/usb/usbip_protocol.txt | 204 ++++++++++++++-- >>>>> tools/usb/usbip/Makefile.am | 2 +- >>>>> tools/usb/usbip/README | 70 ++++-- >>>>> tools/usb/usbip/doc/usbip.8 | 136 +++++++++-- >>>>> tools/usb/usbip/doc/usbipa.8 | 78 +++++++ >>>>> tools/usb/usbip/doc/usbipd.8 | 38 +-- >>>>> tools/usb/usbip/libsrc/usbip_host_common.c | 6 +- >>>>> tools/usb/usbip/libsrc/usbip_host_common.h | 8 +- >>>>> tools/usb/usbip/libsrc/vhci_driver.c | 118 ++++++++-- >>>>> tools/usb/usbip/libsrc/vhci_driver.h | 7 +- >>>>> tools/usb/usbip/src/Makefile.am | 12 +- >>>>> tools/usb/usbip/src/usbip.c | 15 +- >>>>> tools/usb/usbip/src/usbip.h | 10 +- >>>>> tools/usb/usbip/src/usbip_attach.c | 50 +--- >>>>> tools/usb/usbip/src/usbip_bind.c | 4 +- >>>>> tools/usb/usbip/src/usbip_connect.c | 228 >> ++++++++++++++++++ >>>>> tools/usb/usbip/src/usbip_detach.c | 13 +- >>>>> tools/usb/usbip/src/usbip_disconnect.c | 215 +++++++++++++++++ >>>>> tools/usb/usbip/src/usbip_list.c | 17 +- >>>>> tools/usb/usbip/src/usbip_network.h | 4 +- >>>>> tools/usb/usbip/src/usbip_unbind.c | 4 +- >>>>> tools/usb/usbip/src/usbipd.c | 258 >>>> +++------------------ >>>>> tools/usb/usbip/src/usbipd.h | 39 ++++ >>>>> tools/usb/usbip/src/usbipd_app.c | 242 >> +++++++++++++++++++ >>>>> tools/usb/usbip/src/usbipd_dev.c | 252 >>>> ++++++++++++++++++++ >>>>> 25 files changed, 1631 insertions(+), 399 deletions(-) create mode >>>>> 100644 tools/usb/usbip/doc/usbipa.8 create mode 100644 >>>>> tools/usb/usbip/src/usbip_connect.c >>>>> create mode 100644 tools/usb/usbip/src/usbip_disconnect.c >>>>> create mode 100644 tools/usb/usbip/src/usbipd.h create mode 100644 >>>>> tools/usb/usbip/src/usbipd_app.c create mode 100644 >>>>> tools/usb/usbip/src/usbipd_dev.c >>>>> >>>> >>>> >>>> -- >>>> Shuah Khan >>>> Sr. Linux Kernel Developer >>>> Open Source Innovation Group >>>> Samsung Research America(Silicon Valley) shuah.kh@xxxxxxxxxxx >>> >> >> >> -- >> Shuah Khan >> Sr. Linux Kernel Developer >> Open Source Innovation Group >> Samsung Research America(Silicon Valley) shuah.kh@xxxxxxxxxxx > -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America(Silicon Valley) shuah.kh@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
