Re: [Qemu-devel] QEMU Various Vulnerabilities
On [Wed, 02.05.2007 18:21], malc wrote: On Wed, 2 May 2007, Kirill A. Shutemov wrote: http://secunia.com/advisories/25073/ Any comments ? AAM - http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00650.html SB16/DMA - in attachment Thanks. Other Vulnerabilities? -- Regards, Kirill A. Shutemov + Belarus, Minsk + Velesys LLC, http://www.velesys.com/ + ALT Linux Team, http://www.altlinux.com/ signature.asc Description: Digital signature
[Qemu-devel] qemu/hw vmware_vga.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/03 10:09:56 Modified files: hw : vmware_vga.c Log message: Change the PCI IO region start to that hardcoded in VBE bios (reported by Jeremy Katz) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vmware_vga.c?cvsroot=qemur1=1.1r2=1.2
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/03 10:13:54 Modified files: . : vl.c Log message: Remove obsolete variables that came with VMware svga by mistake. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.293r2=1.294
Re: [Qemu-devel] [PATCH] VMware SVGA II emulation
Hi Andrew and others working on vmware hardware, I noticed the small patch made recently to the vmwarevga hardware in qemu, so I decided to test it again. Here is what I am getting on my tests: Host:Kubuntu 7.04 Qemu: CVS from May third. Guest: Windows 2000 Driver: From VMware 5.5.3 build 34685 CPU: Opteron 165 dual core. Guest Memory: 256M Host Memory: 1G KQemu: No [EMAIL PROTECTED]:~/qemu$ qemu -hda win2k.raw -cdrom windows.iso -boot c -m 256 -vmwarevga Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory vmsvga_value_write: guest runs Windows 2000. vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e The initial portion of the boot (text mode bars advancing at the bottom of the screen) works perfectly, then when it switches to graphics mode (Win2k splash screen with small progress bar below) I actually see the progress bar, but only the blue channel and it is disproportionately large. Once the progress bar completes and windows 2k kernel is fully booted, I get small vertical blue bars covering the entire screen (see screenshot). It appears like qemu is no longer responding to paint messages from the window manager because it will not repaint, again as you can see from the screenshot. I'm happy to gather any additional information that may be helpful, and to look at the code if you point me in the right direction. I imagine the best documentation is the source code for the vmware X drivers. Cheers, James -- James Pellow, President Alent Design Solutions www.alentdesignsolutions.com 509-522-5010
Re: [Qemu-devel] QEMU Various Vulnerabilities
In article [EMAIL PROTECTED] Kirill A. Shutemov wrote: On [Wed, 02.05.2007 18:21], malc wrote: On Wed, 2 May 2007, Kirill A. Shutemov wrote: =20 http://secunia.com/advisories/25073/ Any comments ? =20 AAM - http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00650.html SB16/DMA - in attachment Thanks. Other Vulnerabilities? Yesterday I added the debian security patch (90_security.patch from http://security.debian.org/pool/updates/main/q/qemu/qemu_0.8.2-4etch1.diff.gz ) to the FreeBSD qemu ports (had to modify it slightly), cvsweb location of the one for qemu 0.9.0 is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu/files/patch-90_security and the one for the 20070405 cvs snapshot is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu-devel/files/patch-90_security (I haven't checked if it still applies to today's cvs, but it might :) I also disabled the -vmwarevga acceleration code because of the missing range checks, cvsweb of that patch is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu-devel/files/patch-hw-vmware_vga.c HTH, Juergen
Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoints: also for FPU emulation
A similar patch for EXCP_AdEL seems to fix the problems with Linux floating point emulation. Linux uses self modifying code on the stack in the FPU emulation and terminates this code using lwzero,1(zero) (which raises EXCP_AdEL). Sometimes, a system call which follows and is also on the stack does not raise EXCP_SYSCALL but raises EXCP_AdEL, so the calling process gets a signal SIGILL. I tested this by running aptitude on Debian 4.0. It crashs with 4KEc (no FPU, CVS HEAD). It works with default CPU (FPU, CVS HEAD). It works with 4KEc (no FPU, patched CVS HEAD). Stefan Jason Wessel schrieb: It seems there is an issue with the translation block flushing when writing to the code regions in the MIPS full system emulation. Using a 2.6 kernel which is basically running in single user mode, I use an extremely simple program: ... To illustrate the problem further, I attached a patch that makes this problem go away. Of course this is not the right fix, because it only deals with the breakpoint opcode and does not isolate the translated block that had the instruction that changed. In theory you should be able to modify any part of the instruction code from another process with ptrace. Are there any suggestions as to how to fix this the right way? The real hardware of course does not exhibit this issue. Thanks, Jason. Index: qemu/target-mips/helper.c === --- qemu.orig/target-mips/helper.c +++ qemu/target-mips/helper.c @@ -360,6 +360,7 @@ void do_interrupt (CPUState *env) goto set_EPC; case EXCP_BREAK: cause = 9; + tb_flush(env); goto set_EPC; case EXCP_RI: cause = 10;
Re: [Qemu-devel] [PATCH] qemu/hw mips_malta.c mips_pica61.c mips_r4k.c
This workaround fixes the problems with QEMU and Linux FPU emulation (at least in my tests): Index: target-mips/helper.c === RCS file: /sources/qemu/qemu/target-mips/helper.c,v retrieving revision 1.34 diff -u -b -B -r1.34 helper.c --- target-mips/helper.c13 Apr 2007 20:17:54 - 1.34 +++ target-mips/helper.c3 May 2007 20:39:35 - @@ -340,6 +340,7 @@ goto set_EPC; case EXCP_AdEL: cause = 4; +tb_flush(env); goto set_EPC; case EXCP_AdES: cause = 5; Of course, a better solution would be fixing self modifying code. Stefan Thiemo Seufer schrieb: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/04/28 21:07:41 Modified files: hw : mips_malta.c mips_pica61.c mips_r4k.c Log message: Switch default CPU to 24Kf for now, as the Linux FPU emulation in the current qemu mips emulation fails in some cases. (The Linux FPU emulation works on real FPU-less hardware.) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.42r2=1.43
Re: [Qemu-devel] Patch for SDL framebuffer console problem
I did, of course, try this first. The keyboard doesn't work after qemu crashes. The ways I tried to fix this were: 1. reset (didn't work) 2. log in remotely and reboot (always works) 3. log in remotely and try vga_reset, and fbset 800x600-56 (the normal mode On 5/2/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 24 April 2007 2:23 am, Kitambi Leo wrote: I've been using qemu using the Linux framebuffer console, on a machine that's a bit too slow to support X. There have been more than a few snags, but perhaps the most irritating one was that if qemu crashed (and received a SIGSEGV), it would leave the console in an unusable state. This would require me to log into the machine via ssh and reboot it remotely. Type reset and hit enter when this happens. Rob
Re: [Qemu-devel] Patch for SDL framebuffer console problem
I tried various combinations of fixing this problem before I wrote a patch. The keyboard is somehow trashed and/or disabled when qemu crashes in this manner. The methods I tried to fix it were: 1. reset - never works 2. log in remotely and reboot - always works 3. log in remotely and try various combinations of vga_reset and fbset 800x600-56 - always works after I figured out the right order to run the commands in. In the end, I couldn't find any acceptable solutions without a patch, since this is a laptop and I don't always have it connected to a network so I can bail myself out. I apologize for the duplicate message too, I accidently sent the last email without finishing it. On 5/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I did, of course, try this first. The keyboard doesn't work after qemu crashes. The ways I tried to fix this were: 1. reset (didn't work) 2. log in remotely and reboot (always works) 3. log in remotely and try vga_reset, and fbset 800x600-56 (the normal mode On 5/2/07, Rob Landley [EMAIL PROTECTED] wrote: On Tuesday 24 April 2007 2:23 am, Kitambi Leo wrote: I've been using qemu using the Linux framebuffer console, on a machine that's a bit too slow to support X. There have been more than a few snags, but perhaps the most irritating one was that if qemu crashed (and received a SIGSEGV), it would leave the console in an unusable state. This would require me to log into the machine via ssh and reboot it remotely. Type reset and hit enter when this happens. Rob
[Qemu-devel] Spontaneous reboots with FreeBSD + amd64 + kqemu
Hello, I've just moved from an x86 machine to a Core 2 Duo machine, a Thinkpad X60 tablet, running FreeBSD 6.2-STABLE. I've enabled NET_WITH_GIANT and made sure that the kqemu module matches my kernel, which has SMP enabled. When trying to start qemu 0.9.0 with my old WinXP SP2 VMs, I get a Windows loader screen for a short while, and then my host hangs and reboots, giving no error messages. This happens in regular and full virtualization modes. Is there anything I can do to get some debugging information from kqemu? Are there known problems running a 32-bit WinXP with kqemu on a 64-bit FreeBSD or Linux host? Thanks, David
[Qemu-devel] why -hda myimgfile can not work ??
I first create a img file using command qemu-img create myimgfile 10M then I use this img file in my qemu . (qemu -kernel ... -initrd ... -hda myimgfile). but when i am in linux shell , I can not find any hda info even in dmesg, and I can not fdisk or mount hda. who knows what is the problem ??? _ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
