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@xxxxxxxxxxxxxxx/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.opasiak@xxxxxxxxxxx] > Sent: Saturday, December 03, 2016 3:10 AM > To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; shuah.kh@xxxxxxxxxxx; > gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > 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 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. > > Footnotes: > 1 - > https://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg69028.html > > Best regards, > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics -- 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
