diff --git a/README.md b/README.md index 378a9b3..dbf0be4 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ This project is based on [https://github.com/jiegec/usbip](jiegec/usbip), with s Implementing the server side in userspace instead of the kernel's `usbip_host` driver reduces the attack surface considerably. The kernel is not exposed directly to potentially untrusted network input. The userspace server talks to the USB device via /dev/bus/usb/..., and can validate the client's traffic before passing it on to the real USB device. It also makes it possible to implement strong sandboxing via seccomp and namespaces for the server side. The client side is of course still all in the kernel, since making the USB devices visible to the client kernel's drivers is the whole point. But for my use case, the server side is trusted and client side is untrusted, so securing the host side is critical. -There are a few other userspace usbip server implementations around, but as far as I could tell, none of them support isochronous mode. Isochronous is needed for e.g. USB audio devices and webcams. This project does, though my testing so far is limited to USB audio devices which work well. +There are a few other userspace usbip server implementations around, but as far as I could tell, none of them support isochronous mode. Isochronous is needed for e.g. USB audio devices and webcams. This project does, though my testing so far is limited to playback on USB audio devices which work well. This implementation also allows for reversing the connection flow. In standard usbip, the server side listens for connections, and the client side connects to it to access the device. usbip-rs supports having the client listen and the server initiating the connection, which maps much better to my needs. @@ -62,7 +62,7 @@ usbip-rs client listen vsock:5000 usbip-rs test_hid connect vsock:5000 ``` -### Test with a simulated UAC1 loopback audio device +### Test with a simulated UAC1 loopback audio device (not working) ```bash # Client side