Re: KVM crashes when using certain USB device
G wrote:
> On Tue, Jul 21, 2009 at 1:23 AM, Jim Paris wrote:
> > Here's a patch to try. I'm not familiar with the code, but it looks
> > like this buffer might be too small versus the packet lengths that
> > you're seeing, and similar definitions in hw/usb-uhci.c.
> >
> > -jim
> >
> > diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
> > --- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.0 -0400
> > +++ kvm-87/usb-linux.c 2009-07-20 19:15:35.0 -0400
> > @@ -115,7 +115,7 @@
> > uint16_t offset;
> > uint8_t state;
> > struct usb_ctrlrequest req;
> > - uint8_t buffer[1024];
> > + uint8_t buffer[2048];
> > };
> >
> > typedef struct USBHostDevice {
>
> Yes! Applying this patch makes the crash go away! Thank you!
Great!
> In addition to enabling DEBUG and applying your debug printout
> patches, I added a debug printout right above the memcpy()s in
> usb-linux.c, and found that the memcpy() in do_token_in() is called
> multiple time (since do_token_in() is called multiple times for the
> 1993 bytes usb packet I have in my usb sniff dumps), which I guess is
> what's causing a buffer overflow as the offset is pushed beyond 1024
> bytes. But I'm not sure.
Yeah, I think that's it.
> I've looked at the code trying to figure out a better way to solve
> this, now that the problem spot has been found. To me it seems that
> malloc()ing and, when the need arises (the large 1993 bytes packets
> I'm seeing), realloc()ing the buffer, instead of using a statically
> sized buffer, would be the best solution.
Dynamically sizing the buffer might get tricky. It looks like
hw/usb-uhci.c will go up to 2048, while hw/usb-ohci.c and
hw/usb-musb.c could potentially go up to 8192. I think bumping it to
8192 and adding an error instead of overflowing would be good enough.
I'll try to understand the code a bit more and then spin a patch.
> One could of course redefine all buffers to be 8192 bytes instead,
> but that would just be a false sense of security, and perhaps some
> buffers need to be of a particular size to conform to the USB
> specification...
USB packets don't get that large, but the host controllers can combine
them, from what I understand. So it's more a question of what the
host controllers can do.
-jim
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
On Tue, Jul 21, 2009 at 1:23 AM, Jim Paris wrote:
> G wrote:
>> And thanks for your help and suggestions so far, btw.
>
> Here's a patch to try. I'm not familiar with the code, but it looks
> like this buffer might be too small versus the packet lengths that
> you're seeing, and similar definitions in hw/usb-uhci.c.
>
> -jim
>
> diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
> --- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.0 -0400
> +++ kvm-87/usb-linux.c 2009-07-20 19:15:35.0 -0400
> @@ -115,7 +115,7 @@
> uint16_t offset;
> uint8_t state;
> struct usb_ctrlrequest req;
> - uint8_t buffer[1024];
> + uint8_t buffer[2048];
> };
>
> typedef struct USBHostDevice {
Yes! Applying this patch makes the crash go away! Thank you!
In addition to enabling DEBUG and applying your debug printout
patches, I added a debug printout right above the memcpy()s in
usb-linux.c, and found that the memcpy() in do_token_in() is called
multiple time (since do_token_in() is called multiple times for the
1993 bytes usb packet I have in my usb sniff dumps), which I guess is
what's causing a buffer overflow as the offset is pushed beyond 1024
bytes. But I'm not sure.
I've looked at the code trying to figure out a better way to solve
this, now that the problem spot has been found. To me it seems that
malloc()ing and, when the need arises (the large 1993 bytes packets
I'm seeing), realloc()ing the buffer, instead of using a statically
sized buffer, would be the best solution. However, I cannot find a
suitable place to do this, so in the meantime I'll use your patch,
although I do hope the kvm developers will implement a more
stable/reliable malloc()/realloc() solution in the future. 1993 bytes
isn't far from the 2048 bytes limit, and it seems to me that there are
more places in the usb code where statically sized buffer are used
which could lead to more problems of this kind. One could of course
redefine all buffers to be 8192 bytes instead, but that would just be
a false sense of security, and perhaps some buffers need to be of a
particular size to conform to the USB specification...
The differences between the usb code in kvm-72 (which works without a
patch) and kvm-87 are too big for me to try to find out why it works
in kvm-72.
Anyways, I'm happy. Once again, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
G wrote:
> I'm not too familiar with valgrind output, I have only used it on
> smaller programs I've written myself, so I don't know what to think of
> the messages (and amount of messages; valgrind told me to use
> --error-limit=no). I do get a bit nervous from all the complaints
> about uninitialized values and byes, but maybe it's normal for an
> application of kvm's size and type.
I'd be nervous too :) Many of the complaints look harmless, but it's
probably worth fixing them to make the real bugs stand out more.
> > Even though you're having problems with -no-kvm, I suspect this is an
> > upstream qemu issue, so you should probably try the qemu list too.
>
> qemu-de...@nongnu.org? I'll try to figure out the -no-kvm issue first,
> so I can run any commands they might want me to run.
>
> And thanks for your help and suggestions so far, btw.
Here's a patch to try. I'm not familiar with the code, but it looks
like this buffer might be too small versus the packet lengths that
you're seeing, and similar definitions in hw/usb-uhci.c.
-jim
diff -urN kvm-87-orig/usb-linux.c kvm-87/usb-linux.c
--- kvm-87-orig/usb-linux.c 2009-06-23 09:32:38.0 -0400
+++ kvm-87/usb-linux.c 2009-07-20 19:15:35.0 -0400
@@ -115,7 +115,7 @@
uint16_t offset;
uint8_t state;
struct usb_ctrlrequest req;
-uint8_t buffer[1024];
+uint8_t buffer[2048];
};
typedef struct USBHostDevice {
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
Hi there, try to switch to USB 1.1 - not the best way but this helped my Windows XP running and doing things like printing, formatting USB keys or using a Dongle (Aladin, I think, it's also HASP) USB 2.0 was not really working well with KVM :-( Best regards, Erik G wrote: On Thu, Jul 16, 2009 at 9:15 AM, Jim Paris wrote: Hi G, I've continued my attempts to get the HASP dongle working, but with no success: -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
Hi G,
> >> I've continued my attempts to get the HASP dongle working, but with no
> >> success:
...
> Good idea. The results from three test runs after that change are in
> the attached files. The third was done while also dumping the USB bus,
> and the output from that dump is also attached.
The gdb output here looks questionable. Only the second trial seems
to have USB related stuff in the backtrace, so either gdb is wrong or
there's some memory corruption that is causing crashes elsewhere.
Maybe valgrind could help?
You can also add more debugging to the usb code to try to figure out
where things are going wrong. See the attached patch for some printfs
that might help.
Try again with less memory on the guest, like -m 2048, just to reduce
possible problems with the 32-bit guest and address space.
I didn't see anything obviously wrong with the usbmon dumps you sent,
or the debugging that qemu printed out, but I'm not familiar with this
code.
Even though you're having problems with -no-kvm, I suspect this is an
upstream qemu issue, so you should probably try the qemu list too.
-jim
diff -urN kvm-87/usb-linux.c kvm-87-debug/usb-linux.c
--- kvm-87/usb-linux.c 2009-06-23 09:32:38.0 -0400
+++ kvm-87-debug/usb-linux.c 2009-07-16 03:06:22.0 -0400
@@ -209,16 +209,21 @@
static AsyncURB *async_alloc(void)
{
-return (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+AsyncURB *aurb = (AsyncURB *) qemu_mallocz(sizeof(AsyncURB));
+dprintf("husb: allocated %p\n", aurb);
+return aurb;
}
static void async_free(AsyncURB *aurb)
{
+dprintf("husb: freeing %p\n", aurb);
qemu_free(aurb);
}
static void async_complete_ctrl(USBHostDevice *s, USBPacket *p)
{
+dprintf("husb: complete ctrl, host state %d len %d\n",
+ s->ctrl.state, s->ctrl.len);
switch(s->ctrl.state) {
case CTRL_STATE_SETUP:
if (p->len < s->ctrl.len)
@@ -266,6 +271,7 @@
aurb, aurb->urb.status, aurb->urb.actual_length);
if (p) {
+ dprintf("husb: p=%p\n", p);
switch (aurb->urb.status) {
case 0:
p->len = aurb->urb.actual_length;
@@ -280,11 +286,12 @@
p->len = USB_RET_NAK;
break;
}
-
+ dprintf("husb: completing, p->len=%d\n", p->len);
usb_packet_complete(p);
}
async_free(aurb);
+
}
}
Re: KVM crashes when using certain USB device
On Sat, Jul 4, 2009 at 12:01 PM, G wrote: > On Fri, Jul 3, 2009 at 6:18 PM, Jim Paris wrote: >> G wrote: >>> Hello again, >>> >>> I've continued my attempts to get the HASP dongle working, but with no >>> success: [snip] >>> Anyone got any ideas what I might try out to find the cause for the >>> crashes? >> >> You might try uncommenting "//#define DEBUG" at the top of usb-linux.c >> to get some more verbose output from qemu. > > Good idea. The results from three test runs after that change are in > the attached files. The third was done while also dumping the USB bus, > and the output from that dump is also attached. I have now also generated USB dumps using Wireshark, which captures the entire(?) packet contents instead of just the first 32 bytes. Is anyone interested in analyzing them, perhaps by somehow replaying them (similar to using tcpreplay) to generate KVM crashes on their machine? Let me know and I'll mail/post them. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
On Fri, Jul 3, 2009 at 6:18 PM, Jim Paris wrote: > G wrote: >> Hello again, >> >> I've continued my attempts to get the HASP dongle working, but with no >> success: >> >> Downloaded kvm-72.tar.gz through kvm-87.tar.gz to find out when the >> problem first appear, as kvm-72 is working. Unfortunately, kvm-72 >> through kvm-82 fails to compile on my Debian system with kernel 2.6.30 >> and gcc 4.3, and kvm-83 crashes in the same way that kvm-87 crashes. >> >> I have also tested two other USB devices: a C-Pen (www.cpen.com) and a >> GEM card reader, both successfully. So it seems it is the HASP >> dongle/driver combo which is doing something naughty that makes KVM >> versions newer than kvm-72 crash... >> >> Anyone got any ideas what I might try out to find the cause for the >> crashes? > > You might try uncommenting "//#define DEBUG" at the top of usb-linux.c > to get some more verbose output from qemu. Good idea. The results from three test runs after that change are in the attached files. The third was done while also dumping the USB bus, and the output from that dump is also attached. Scenario: boot, install the HASP SRM drivers, after install completes issue "usb_add host:0529:0001" command in qemu monitor, dumps core after windows discovers qemu usb hub. % qemu-system-x86_64 -no-acpi -hda WinXP_eng_32bit_kvm87.img -m 4096 -net nic -net user -usb -monitor stdio -usbdevice tablet QEMU 0.10.50 monitor - type 'help' for more information (qemu) usb_add host:0529:0001 husb: opened /proc/bus/usb/devices husb: using proc file-system with /proc/bus/usb husb: open device 4.4 husb: opened /proc/bus/usb/004/004 === begin dumping device descriptor data === 12 01 00 02 ff 00 00 08 29 05 01 00 21 03 01 02 00 01 09 02 14 00 01 01 00 80 19 09 04 00 00 00 ff 00 00 00 02 ff === end dumping device descriptor data === husb: claiming interfaces. config -1 husb: i is 18, descr_len is 38, dl 9, dt 2 husb: config #1 need -1 husb: 1 interfaces claimed for configuration 1 husb: grabbed usb device 4.4 (qemu) husb: reset device 4.4 husb: claiming interfaces. config 1 husb: i is 18, descr_len is 38, dl 9, dt 2 husb: config #1 need 1 husb: 1 interfaces claimed for configuration 1 husb: ctrl type 0x80 req 0x6 val 0x100 index 0 len 64 husb: submit ctrl. len 72 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 18 husb: reset device 4.4 husb: claiming interfaces. config 1 husb: i is 18, descr_len is 38, dl 9, dt 2 husb: config #1 need 1 husb: 1 interfaces claimed for configuration 1 husb: ctrl type 0x0 req 0x5 val 0x2 index 0 len 0 husb: ctrl set addr 2 husb: ctrl type 0x80 req 0x6 val 0x100 index 0 len 18 husb: submit ctrl. len 26 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 18 husb: ctrl type 0x80 req 0x6 val 0x200 index 0 len 9 husb: submit ctrl. len 17 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 9 husb: ctrl type 0x80 req 0x6 val 0x200 index 0 len 255 husb: submit ctrl. len 263 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 20 husb: ctrl type 0x80 req 0x6 val 0x3ee index 0 len 18 husb: submit ctrl. len 26 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status -32 alen 0 husb: ctrl type 0x80 req 0x6 val 0x3ee index 0 len 18 husb: submit ctrl. len 26 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status -32 alen 0 husb: ctrl type 0x80 req 0x6 val 0x3ee index 0 len 18 husb: submit ctrl. len 26 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status -32 alen 0 husb: reset device 4.4 husb: claiming interfaces. config 1 husb: i is 18, descr_len is 38, dl 9, dt 2 husb: config #1 need 1 husb: 1 interfaces claimed for configuration 1 husb: ctrl type 0x80 req 0x6 val 0x100 index 0 len 64 husb: submit ctrl. len 72 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 18 husb: reset device 4.4 husb: claiming interfaces. config 1 husb: i is 18, descr_len is 38, dl 9, dt 2 husb: config #1 need 1 husb: 1 interfaces claimed for configuration 1 husb: ctrl type 0x0 req 0x5 val 0x4 index 0 len 0 husb: ctrl set addr 4 husb: ctrl type 0x80 req 0x6 val 0x100 index 0 len 18 husb: submit ctrl. len 26 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 18 husb: ctrl type 0x80 req 0x6 val 0x200 index 0 len 9 husb: submit ctrl. len 17 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 9 husb: ctrl type 0x80 req 0x6 val 0x300 index 0 len 255 husb: submit ctrl. len 263 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 4 husb: ctrl type 0x80 req 0x6 val 0x302 index 1033 len 255 husb: submit ctrl. len 263 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 32 husb: ctrl type 0x80 req 0x6 val 0x300 index 0 len 255 husb: submit ctrl. len 263 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 4 husb: ctrl type 0x80 req 0x6 val 0x302 index 1033 len 255 husb: submit ctrl. len 263 aurb 0x176ed10 husb: async completed. aurb 0x176ed10 status 0 alen 32 husb: ctrl type 0x80 req 0x6 val
Re: KVM crashes when using certain USB device
G wrote: > Hello again, > > I've continued my attempts to get the HASP dongle working, but with no > success: > > Downloaded kvm-72.tar.gz through kvm-87.tar.gz to find out when the > problem first appear, as kvm-72 is working. Unfortunately, kvm-72 > through kvm-82 fails to compile on my Debian system with kernel 2.6.30 > and gcc 4.3, and kvm-83 crashes in the same way that kvm-87 crashes. > > I have also tested two other USB devices: a C-Pen (www.cpen.com) and a > GEM card reader, both successfully. So it seems it is the HASP > dongle/driver combo which is doing something naughty that makes KVM > versions newer than kvm-72 crash... > > Anyone got any ideas what I might try out to find the cause for the > crashes? You might try uncommenting "//#define DEBUG" at the top of usb-linux.c to get some more verbose output from qemu. -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM crashes when using certain USB device
Hello again, I've continued my attempts to get the HASP dongle working, but with no success: Downloaded kvm-72.tar.gz through kvm-87.tar.gz to find out when the problem first appear, as kvm-72 is working. Unfortunately, kvm-72 through kvm-82 fails to compile on my Debian system with kernel 2.6.30 and gcc 4.3, and kvm-83 crashes in the same way that kvm-87 crashes. I have also tested two other USB devices: a C-Pen (www.cpen.com) and a GEM card reader, both successfully. So it seems it is the HASP dongle/driver combo which is doing something naughty that makes KVM versions newer than kvm-72 crash... Anyone got any ideas what I might try out to find the cause for the crashes? On Thu, Jul 2, 2009 at 5:42 PM, G wrote: > Hello, > > As the subject says, kvm crashes for me, when I'm trying to use an > Aladdin HASP USB dongle. > > Short background: for over a year I have used kvm to run a Windows XP > Professional 32bit SP2 install with the EnCase software package, which > requires an Aladdin HASP USB dongle. The last working installation > used Debian unstable's kvm-72 and qemu 0.10.5 packages, together with > linux 2.6.29.4 (and Win XP 32 bit SP2, EnCase 6.13 (I have prevoiusly > also successfully used EnCase 4.22a with an older Aladdin HASP USB > dongle)). In an attempt to increase disk performance I upgraded to > kvm-87, and then my problems began. > > Running kvm-87 works fine up until the point when the Aladdin HASP > driver wants to talk to the dongle. For example, I did one test run > with a clean Windows install where I installed EnCase 6.13 and the > dongle drivers, started up EnCase in Acquisition Mode, acquired the > running virtual hard disk while playing Solitaire (to keep both disk > and graphics going), and it went fine. Then, when I enter "usb_add > host:0529:0001" in the qemu monitor it takes somewhere between a few > seconds up to a minute or two before kvm crashes and dumps core. > > Only installing the drivers without entering "usb_add host:0529:0001" > in the qemu monitor does not cause problems, I can keep on using the > system (as just described in previous paragraph). > > Only entering "usb_add host:0529:0001" in the qemu monitor (and then > having "Found new hardware" pop up and selecting "Cancel") without > having the drivers installed does not cause problems, I can keep on > using the system. > > I have tried out the things described at http://www.linux-kvm.org/page/Bugs ; > -no-kvm-irqchip and -no-kvm-pit only slows the system down, it still crashes. > -no-kvm crashes on startup (see the attached file crash3.txt). > > All these test runs make me guess that the problem lies somewhere in > kvm's USB code, and is triggered by the Aladdin HASP drivers, unless > there is something fundamentally wrong with my install (the immediate > crash with -no-kvm might indicate that). I can however see nothing > obviously wrong with my install and therefore suspect kvm. > > Three files, describing three different test runs (including gdb > backtraces) which all crash at some point, are attached to this mail. > They are generated on a Fujitsu Siemens Celsius workstation with an > "Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz" (according to /proc/cpuinfo), > 4GB RAM, running Linux 2.6.30 x86_64, and kvm-87 and qemu-kvm-0.10.5 > downloaded from Sourceforce using the link on > http://www.linux-kvm.org/page/Downloads . No Debian kvm or qemu > packages installed, and I have made sure that I really use the kvm-87 > kernel modules and not the ones that come with the kernel. > > The exact same problems also show up when running the same kvm/qemu > versions and the same virtualized versions (of Win and EnCase), and on > both Linux 2.6.29.4 and 2.6.30, on a HP ProLiant DL380 G5 with 12GB > RAM and an Intel Xeon 5160 (don't know if it's a quad core or two dual > cores; in any case, it's four cores total). That is the intended > production system, and the system on which I have successfully been > running Windows and EnCase on older kvm versions (kvm-72 is working, I > don't remember if I've used any version before that). > > qemu-kvm-0.10.5 is installed like this: > ./configure > make > make install > > kvm-87 is installed like this: > ./configure --enable-debug > make > make install > > I see nothing wrong with those installation methods, although I get no > "kvm" binary, and instead have to use qemu-system-x86_64 to run. > > I'd be happy to do more test runs using any flags you want me to try > in order to pin this problem down. Unless, of course, I've done > something wrong, in which case I will gladly receive instructions on > how to correctly use kvm to get this working (but it's working with > kvm-72...). I have already tried several earlier versions of kvm such > as Debian unstable's kvm-85, kvm-83, and kvm-79, using the kvm modules > from the kernel tree, and they all crash too. But kvm-72 works with > the kvm modules from the kernel. > > I can also supply more output from kvm compilation, kernel config etc.
