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
