RE: [PATCH v13 00/10] usbip: exporting devices
Hello, > Generally what this series does is just changing the initiator role. Please note that this series 'adds' new operation. Current (bind-and attach) operation is kept as it is. New operation is available if the new daemon is started. > 1) I would like to see some real numbers of performance difference not > just "smoother motion" like described in [1]. Then we can see what's > the real performance difference between this and simple web > sockets/tcp tunnel > Footnotes: > 1 - > https://www.mail-archive.com/linux-usb@vger.kernel.org/msg69028.html Please note that userspace URBs transmission and WebSocket command/ daemon has been excluded at v7 of this set. Currently this set is intended to use with tunneling proxy. > 2) This series contains some fixes/improvements which in my opinion > should be split into separate series on which this one may depend. 4 patches have been applied which are found developing this series. usbip: adding names db to port operation usbip: safe completion against unbind operation usbip: event handler as one thread usbip: deletion of incorrect socket descriptor checking I remind your comments and will make new patches. > 4) In most patches there are some mistakes which should be fixed > before applying. I will create v14. Best Regards, n.iwata // > -Original Message- > From: Krzysztof Opasiak [mailto:k.opas...@samsung.com] > Sent: Saturday, December 03, 2016 3:10 AM > To: fx IWATA NOBUO; valentina.mane...@gmail.com; shuah...@samsung.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org > Cc: fx MICHIMURA TADAO; Krzysztof Opasiak > Subject: Re: [PATCH v13 00/10] usbip: exporting devices > > Dear all, > > On 11/22/2016 07:48 AM, 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. > > > > This feature looks for me like a knife. It may be useful in some cases but > you may also hurt your self or some one else quite easily. > > > NOTE: > > Directions of URBs requests and responses are not changed. Only > > direction of connection establishment initiated with usbip command is > > added to exsiting one. > > > > Generally what this series does is just changing the initiator role. > > Classically Client connects to a server to get some device which is > available. > > This patch allows to leave your server waiting for new devices to be > connected to it from a remote machine. > > I see some points when it may be useful. For example you can start some > virtual machine and connect different devices to it and check what's the > system reaction. This may be useful is you would like to test for example > some malware if it's playing badly with some USB devices. > > Of course you could do the same thing without this series but then you need > to interact with the VM each time when you would like to connect and > disconnect the device. > > > 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. > > > > If you combine what I wrote above with vUDC you can get quite nice > automated testing laboratory for USB malware investigation as you can > emulate any USB device quite easily and then simply attach it to VM. > > > 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 'desconnect' > > > > 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 certific
RE: [PATCH v13 00/10] usbip: exporting devices
late response. I took time to write the answer. Thank you for taking time, n.iwata // > -Original Message- > From: Shuah Khan [mailto:shuah...@samsung.com] > Sent: Saturday, December 03, 2016 12:49 AM > To: fx IWATA NOBUO; valentina.mane...@gmail.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org > Cc: fx MICHIMURA TADAO; Shuah Khan; Shuah Khan > Subject: Re: [PATCH v13 00/10] usbip: exporting devices > > 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...@samsung.com] > >> Sent: Friday, December 02, 2016 9:39 AM > >> To: fx IWATA NOBUO; valentina.mane...@gmail.com; > >> gre...@linuxfoundation.org; linux-usb@vger.kernel.org > >> 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 at
Re: [PATCH v13 00/10] usbip: exporting devices
Dear all, On 11/22/2016 07:48 AM, 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. > This feature looks for me like a knife. It may be useful in some cases but you may also hurt your self or some one else quite easily. > NOTE: > Directions of URBs requests and responses are not changed. Only > direction of connection establishment initiated with usbip command is > added to exsiting one. > Generally what this series does is just changing the initiator role. Classically Client connects to a server to get some device which is available. This patch allows to leave your server waiting for new devices to be connected to it from a remote machine. I see some points when it may be useful. For example you can start some virtual machine and connect different devices to it and check what's the system reaction. This may be useful is you would like to test for example some malware if it's playing badly with some USB devices. Of course you could do the same thing without this series but then you need to interact with the VM each time when you would like to connect and disconnect the device. > 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. > If you combine what I wrote above with vUDC you can get quite nice automated testing laboratory for USB malware investigation as you can emulate any USB device quite easily and then simply attach it to VM. > 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 'desconnect' > > 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. > There are also other security implications. With this patch it's quite easy to leak some USB outside restricted company network. Let's say that malicious employee has server and you run usbipa on it on port 9418 which is git (just example). Then he goes to his company connect his restricted USB license key or anything else to the computer and simply pass it using USB/IP to his remote server. > 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. > After reading the whole series I realized that USB/IP tools lacks support for multiple instances of vhci which we have now available and configurable via Kconfig. > 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. > I wrote my opinion about wording in patch 9. All in all. In my humble opinion the idea in this series is worth discussion but: 1) I would like to see some real numbers of performance difference not just "smoother motion" like described in [1]. Then we can see what's the real performance difference between this and simple web sockets/tcp tunnel 2) This series contains some fixes/improvements which in my opinion should be split into separate series on which this one may depend. 3) I don't like the fact that we are sending so much information about the device during connect/disconnect operation as it's never used. is there any RFC or other document which standardize this message? If not then maybe we can just drop redundant information? 4) In most patches there are some mistakes which should be fixed before applying.
Re: [PATCH v13 00/10] usbip: exporting devices
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...@samsung.com] >> Sent: Friday, December 02, 2016 9:39 AM >> To: fx IWATA NOBUO; valentina.mane...@gmail.com; >> gre...@linuxfoundation.org; linux-usb@vger.kernel.org >> 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
RE: [PATCH v13 00/10] usbip: exporting devices
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. > 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. > 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. In new way, they are not. The linux machine which has device doesn't have server daemon. I'd like to confirm the definition to answer rest of questions. Best Regards, n.iwata // > -Original Message- > From: Shuah Khan [mailto:shuah...@samsung.com] > Sent: Friday, December 02, 2016 9:39 AM > To: fx IWATA NOBUO; valentina.mane...@gmail.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org > 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 > detai
Re: [PATCH v13 00/10] usbip: exporting devices
l 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...@samsung.com] >> Sent: Thursday, November 24, 2016 1:43 AM >> To: fx IWATA NOBUO; valentina.mane...@gmail.com; >> gre...@linuxfoundation.org; linux-usb@vger.kernel.org >> 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 >>> = = = >>>
Re: [PATCH v13 00/10] usbip: exporting devices
On 11/23/2016 10:30 AM, Greg KH wrote: > On Tue, Nov 22, 2016 at 03:48:09PM +0900, Nobuo Iwata wrote: >> Dear all, >> >> This series of patches adds exporting device operation to USB/IP. > > I would _love_ it if some of the people who are listed as MAINTAINERS of > this code could actually review these patch series. I don't think I've > seen that happen yet, which isn't good... > I'm not listed as maintainer but I used to be a tutor for students doing vudc. I have some experience with USB/IP so I will try to help. I tried to find some spare time for this series for quite a long time and finally I got it!;) I managed to review first 5 patches but it's getting late in Poland (at least for sitting in an office in a front of computer;)) so I will get back to this tomorrow. Best regards, -- Krzysztof Opasiak Samsung R Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v13 00/10] usbip: exporting devices
Hello, > 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. --- > 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 --busid - Bind usbip-host.ko to the device with . - The USB device of is connected to remote host! dev:# usbip disconnect --remote --busid - The USB device with 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...@samsung.com] > Sent: Thursday, November 24, 2016 1:43 AM > To: fx IWATA NOBUO; valentina.mane...@gmail.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org > 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
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
Re: [PATCH v13 00/10] usbip: exporting devices
On 11/23/2016 02:30 AM, Greg KH wrote:
> On Tue, Nov 22, 2016 at 03:48:09PM +0900, Nobuo Iwata wrote:
>> Dear all,
>>
>> This series of patches adds exporting device operation to USB/IP.
>
> I would _love_ it if some of the people who are listed as MAINTAINERS of
> this code could actually review these patch series. I don't think I've
> seen that happen yet, which isn't good...
>
> {hint hint hint}
>
> greg k-h
>
I started reviewing the patch series. Didn't get a chance to go
through all of them yet.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 00/10] usbip: exporting devices
On Tue, Nov 22, 2016 at 03:48:09PM +0900, Nobuo Iwata wrote:
> Dear all,
>
> This series of patches adds exporting device operation to USB/IP.
I would _love_ it if some of the people who are listed as MAINTAINERS of
this code could actually review these patch series. I don't think I've
seen that happen yet, which isn't good...
{hint hint hint}
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v13 00/10] usbip: exporting devices
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. 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 |+
