linux-kernel - USBIP protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Aug 2008 08:02:24 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Greg KH <greg@...ah.com>, bgmerrell@...ell.com,
	hirofuchi@...rs.sourceforge.net
Cc:	linux-kernel@...r.kernel.org, usbip-devel@...ts.sourceforge.net
Subject: USBIP protocol


I'm in the middle of implementing a userspace client for usbip and I
strongly feel that the protocol needs to be changed before it is merged.

 - I'm unconvinced that TCP is the correct protocol to be running this over.
   I understand the reluctance to use UDP, but the protocol is fundamentally
   packet-based.  If TCP is used, the delimitation of packets within the
   stream needs to be much more robust.  I've managed to wedge the VHCI driver
   a number of times in ways that just wouldn't be possible if we were using
   a packet protocol instead of a stream protocol.
 - Endianness.  This is a mess.  The usbip protocol is big-endian, but the
   encapsulated usb protocol is little-endian.  This doesn't matter to the
   people who are just tunnelling usb from one computer to another, but for
   someone implementing a usbip client, it's very confusing.
 - The protocol needs an officially assigned port number.  Port 3240 is 
   already assigned to Tony Matthews <tmatthews&triomotion.com> February
   2002 (see http://www.iana.org/assignments/port-numbers)
 - There are actually two completely different protocols in use.  First,
   the usbipd daemon listens on port 3240, and handles device discovery.
   When usbip successfully attaches to usbipd, both sides of the connection
   pass the socket fd into the kernel and the protocol changes.
 - The protocol sends a 48-byte packet header for every command (and every
   response).  It's cunningly hidden as a union.
   
I think the protocol would be immeasurably improved by going through the
IETF RFC process and getting feedback from networking experts.  Failing
that, I have some suggestions about how to improve it.  I was hoping to
get my client finished before I started mucking with the protocol though.

(I have some other comments on the implementation, but they're a separate
issue).

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/