qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: TJ <dimitry.ishenko@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Guest OS hangs on usb_add
Date: Thu, 24 Jun 2010 00:45:52 -0400	[thread overview]
Message-ID: <4C22E300.5020109@gmail.com> (raw)
In-Reply-To: <AANLkTinEa7pgxPtq2iKS7ETCky_ICI5PubVAWLwcNi0c@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]


> ---------- Forwarded message ----------
> From: Timothy Jones <one.timothy.jones@gmail.com>
> Date: Wed, Jun 23, 2010 at 9:07 PM
> Subject: Guest OS hangs on usb_add
> To: qemu-devel@nongnu.org
> 
> 
> With some digging around I found out that the qemu hangs in
> usb_host_claim_interfaces, which is caused by screwed up usb
> descriptor. The device reports the following:
> 
> (gdb) p dev->descr_len
> $21 = 50
> (gdb) p /x dev->descr[0]@50
> $23 = {0x18, 0x1, 0x0, 0x1, 0xff, 0xff, 0xff, 0x8, 0x47, 0x46, 0x0,
> 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x9, 0x2, 0x20,
>  0x0, 0x1, 0x1, 0x0, 0x80, 0x19, 0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0xff,
> 0xff, 0x0, 0x7, 0x5, 0x81, 0x2, 0x40, 0x0, 0x0,
>  0x7, 0x5, 0x3, 0x2, 0x10, 0x0, 0x0}
> 
> The first 0x18 (Device Descriptor bLength) is supposed to be decimal
> 18, not hex! According to USB spec, if the device reports size greater
> than expected, the host is supposed ignore the extra bytes. So qemu
> behaves correctly here. However, with this length, the following
> Configuration Descriptor length falls on a 0x0 and so the qemu spins
> in an endless loop. (This is prolly something that should be detected
> and reported as error by qemu.)
> 
> My question is: This 0x18 -- is this something that comes from the
> device itself (ie, firmware bug)? Or does it come from the USB
> subsystem?
> 
> I don't mind writing a small patch to make descriptor parsing a bit
> more intelligent, but I am very unfamiliar with the code, so I might
> botch things up. Or is the above data sufficient for one of the devs
> to take a look at the code and improve it?
> 
> Thank you.
> 
> -TJ
> 

Here is small patch that fixed my problem.

In looking at the USB spec, it seems pretty clear cut about the whole
device/config/interface/endpoint descriptor hierarchy, so the
usb_host_claim_interfaces can be optimized instead of parsing through each
descriptor to skip through config descriptors using wTotalLength field. And
again, some checks can be done for descriptor types and/or sizes.

Just my 2 cents.

-TJ



[-- Attachment #2: hex-dev-descr-len.patch --]
[-- Type: text/plain, Size: 705 bytes --]

--- hw/usb.h.orig	2010-06-23 22:55:27.649182672 -0400
+++ hw/usb.h	2010-06-23 22:56:09.937910171 -0400
@@ -117,6 +117,8 @@
 #define USB_DT_INTERFACE		0x04
 #define USB_DT_ENDPOINT			0x05
 
+#define USB_DT_DEVICE_LEN		18
+
 #define USB_ENDPOINT_XFER_CONTROL	0
 #define USB_ENDPOINT_XFER_ISOC		1
 #define USB_ENDPOINT_XFER_BULK		2
--- usb-linux.c.orig	2010-06-23 22:56:23.191339634 -0400
+++ usb-linux.c	2010-06-24 00:08:19.437515669 -0400
@@ -299,6 +299,9 @@
 
     i = 0;
     dev_descr_len = dev->descr[0];
+    if (dev_descr_len == 0x18)
+        dev_descr_len = USB_DT_DEVICE_LEN; /* for buggy device(s) reporting len in hex */
+
     if (dev_descr_len > dev->descr_len) {
         goto fail;
     }



  parent reply	other threads:[~2010-06-24  4:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-23 18:21 [Qemu-devel] Guest OS hangs on usb_add Timothy Jones
2010-06-24  1:07 ` Timothy Jones
     [not found]   ` <AANLkTinEa7pgxPtq2iKS7ETCky_ICI5PubVAWLwcNi0c@mail.gmail.com>
2010-06-24  4:45     ` TJ [this message]
2010-06-24 17:59       ` David S. Ahern
2010-06-24 18:22         ` TJ
2010-06-25 16:32       ` Gianni Tedesco
2010-06-25 17:23         ` TJ
2010-06-28 12:32           ` Gianni Tedesco
2010-06-28 14:36             ` TJ
2010-06-24  6:42   ` Markus Armbruster
2010-06-24 18:35     ` TJ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C22E300.5020109@gmail.com \
    --to=dimitry.ishenko@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).