Re: [Qemu-devel] bug report : kqemu and self-writing code
Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard [EMAIL PROTECTED] wrote:
Are you sure that the bug is really in kqemu ? It is possible that
your guest kernel implements a security system which prevents self
modifying code using segment limits which QEMU does not check (but
kqemu checks them !).
Regards,
Fabrice.
Even Rouault wrote:
Guest OS : Linux 2.6.15-1.2054_FC5 i686 (Fedora Core 5 i386)
Host OS: Linux 2.6.12-10-amd64-k8 #1 x86_64 (Ubuntu 5.10 amd64)
QEMU Version : today CVS compiled with kqemu support
KQEMU : 1.3.0pre6
Binary used : qemu-system-x86-64 (so kqemu user-mode is used)
I'm running the simple C code attached. With kqemu user-mode, this
fails (sigsegv) with the following warning in dmesg :
audit(1146505373.813:12): avc: denied { execheap } for pid=1860
comm=selfmodifying scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
Erreur de segmentation
Without kqemu enabled, it runs fine.
#define _XOPEN_SOURCE 600
#include sys/mman.h
#include unistd.h
#include stdlib.h
#include stdio.h
int main(int argc, char** argv)
{
int pagesize = getpagesize();
unsigned char* addr = NULL;
posix_memalign((void**)addr, pagesize, pagesize);
mprotect(addr, pagesize, PROT_WRITE | PROT_READ | PROT_EXEC);
addr[0] = 0x8b; addr[1] = 0x44; addr[2] = 0x24; addr[3] =
0x04; /* mov0x4(%esp),%eax */ addr[4] = 0x83; addr[5] = 0xc0;
addr[6] = 0x01; /* add$0x1,%eax */ addr[7] = 0xc3; /* ret */
printf(10+1=%d\n, ((int (*)(int))addr)(10));
free(addr);
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Kevin F. Quinn
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug report : kqemu and self-writing code
I had a similar problem, but only when not using kqemu.
When using a stack overflow exploit, the shellcode provided only
executes when using kqemu. I can attribute this to either the
shellcode being in a different location (maybe someone can clarify
this, is qemu using a different memory layout e.g. stack is located in
a different virtual address), or qemu does not translate the shellcode
located in the stack and instead causes a memory fault (again i have
no idea why this should be the case).
When using kqemu the shellcode executes normally.
I did not have any time to investigate the reasons, but i have a hunch
it is the probably the translation.
If anyone knows what the problem is, i would be glad to write a patch.
On 02/05/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard [EMAIL PROTECTED] wrote:
Are you sure that the bug is really in kqemu ? It is possible that
your guest kernel implements a security system which prevents self
modifying code using segment limits which QEMU does not check (but
kqemu checks them !).
Regards,
Fabrice.
Even Rouault wrote:
Guest OS : Linux 2.6.15-1.2054_FC5 i686 (Fedora Core 5 i386)
Host OS: Linux 2.6.12-10-amd64-k8 #1 x86_64 (Ubuntu 5.10 amd64)
QEMU Version : today CVS compiled with kqemu support
KQEMU : 1.3.0pre6
Binary used : qemu-system-x86-64 (so kqemu user-mode is used)
I'm running the simple C code attached. With kqemu user-mode, this
fails (sigsegv) with the following warning in dmesg :
audit(1146505373.813:12): avc: denied { execheap } for pid=1860
comm=selfmodifying scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
Erreur de segmentation
Without kqemu enabled, it runs fine.
#define _XOPEN_SOURCE 600
#include sys/mman.h
#include unistd.h
#include stdlib.h
#include stdio.h
int main(int argc, char** argv)
{
int pagesize = getpagesize();
unsigned char* addr = NULL;
posix_memalign((void**)addr, pagesize, pagesize);
mprotect(addr, pagesize, PROT_WRITE | PROT_READ | PROT_EXEC);
addr[0] = 0x8b; addr[1] = 0x44; addr[2] = 0x24; addr[3] =
0x04; /* mov0x4(%esp),%eax */ addr[4] = 0x83; addr[5] = 0xc0;
addr[6] = 0x01; /* add$0x1,%eax */ addr[7] = 0xc3; /* ret */
printf(10+1=%d\n, ((int (*)(int))addr)(10));
free(addr);
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Kevin F. Quinn
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS]
Hi! The current CVS QEMU Makefile builds qemu-system-mips binary which really emulates a little-endian system and should be renamed to the qemu-system-mipsel [EMAIL PROTECTED] qemu/bin]$ ls qemuqemu-i386 qemu-mipsel qemu-sparcqemu-system-ppc qemu-armqemu-img qemu-ppc qemu-system-arm qemu-system-sparc qemu-armeb qemu-mips qemu-sh4 qemu-system-mips qemu-system-x86_64 Is it possible to build _both_ qemu-system-mips* for LE and BE support like userspace does ? -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: solaris-sparc-slirp fix
Leonardo E. Reiter [EMAIL PROTECTED] wrote: Ben, You can use the patch I posted here recently to get QEMU to fix the BGR problem internally. It doesn't have to be done at the VNC level - and in fact, this way, you can use it on the Solaris native X server (or even SunRays) in 24-bit color mode. I am attaching a new version of the patch, complete with the detection logic (to make it automatic), against today's CVS. Tried it, still didn't come up correctly, with or without the -bgr flag and using the vnc option. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: solaris-sparc-slirp fix
Hi, On Tue, 2 May 2006, Ben Taylor wrote: Tried it, still didn't come up correctly, with or without the -bgr flag and using the vnc option. I guess the problem is that client format and pixel format are different. The RFB protocol says that the server has to convert to the client format before sending. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: solaris-sparc-slirp fix
Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Tue, 2 May 2006, Ben Taylor wrote: Tried it, still didn't come up correctly, with or without the -bgr flag and using the vnc option. I guess the problem is that client format and pixel format are different. The RFB protocol says that the server has to convert to the client format before sending. Well, if the code that Leo used was from a previous rgb patch, I know that worked on Solaris/Sparc systems a year ago if displaying on a native screen. I'll try it local and see how it goes today. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS
On Tue, 2 May 2006, Marius Groeger wrote: again, a current version of my FPU patch for MIPS. Fabrice, I tried to Sorry, hunk #1 of the target-mips/op_mem.c patch got out wrong. (I wanted to remove other feature patches[1] first and seemed to have messed up in doing so.) Just delete this hunk before appling the patch. Sorry and Best Regards Marius [1] qemu-0.8.0-mips-cp0.patch, qemu-0.8.0-mips-lwu.patch, qemu-0.8.0-mips-aligned-pc.patch -- Marius Groeger [EMAIL PROTECTED] SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VLAN connection issue between Qemu instances.
Hello Mark, thanks a lot for your advice! This really solves the issue and now I'm able to ping other instance and ssh to its openbsd. Thanks! Karel On Tue, 2 May 2006, Mark Jonckheere wrote: I did try to reply via the mailing-list, but after three days my posting is still missing: qemu -hda openbsd-fw1.img -net nic,macaddr=22:33:77:55:66:00 -net socket,listen=:11234 qemu -hda openbsd-fw2.img -net nic,macaddr=11:22:33:44:55:66 -net --^ (fixed width font) socket,connect=silence:11234 The first byte of your MAC-address is odd, this indicates that it is a multicast-address. Strange things will happen if you use a multicast address where you should use a unicast address. Please redo your tests with MAC-addresses 52:54:00:11:22:33 and 52:54:00:12:34:56 Greetings, Mark. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix memory leaks in ELF loader
Fabrice Bellard wrote: Why adding several labels ? qemu_free(NULL) is perfectly valid. I would just add the missing qemu_free(phdr) ... Okay. Wasn't sure about this ;) Do you want a patch for qemu_free(phdr)? Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS]
Alexander Voropay wrote: The current CVS QEMU Makefile builds qemu-system-mips binary which really emulates a little-endian system and should be renamed to the qemu-system-mipsel With configure --target-list you can select mips-softmmu or mipsel-softmmu. So I think it's a good idea to extend build system to generate mips-softmmu - qemu-system-mips (big endian) mipsel-softmmu - qemu-system-mipsel (little endian) Has anybody a patch for this? Is it possible to build _both_ qemu-system-mips* for LE and BE support like userspace does ? I don't think so at the moment. I'm not sure what happens if both (little and big endian) targets are selected by configure. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] vnc patch
-usbdevice tablet emulates a absolute position USB HID device instead of a PS/2 mouse, so there is no need for messy mouse calibration when using VNC. It also allows you to get rid of the need to have the SDL version 'grab' the mouse. On Sat, Apr 29, 2006 at 07:36:01PM +0200, Christian MICHON wrote: did I understand well ? 1) there's a rework of the original vnc patch 2) there are no problems of sync using the usb tablet what is this usb tablet stuff? do I really need a usb tablet connected to the host or this is yet another emulated hardware inside the qem guest ? If this is the case, it means the client OS must have the proper drivers, etc... I'm a bit lost. Christian On 4/29/06, Anthony Liguori [EMAIL PROTECTED] wrote: Lonnie Mendez wrote: Lonnie Mendez wrote: There is another vnc patch by Anthony Liguori (same person involved with the tablet along with others). From what I've heard it will reduce the bandwidth usage greatly. Also, afaik this is still under development. The source was posted on the irc channel a few days ago: http://www.cs.utexas.edu/users/aliguori/vnc.diff The mercurial tree is located at http://hg.codemonkey.ws/qemu-vnc If you go to Manifest - Changeset you can download a static tarball if you're unfamiliar with mercurial. It's in a pretty good state now. I don't think there's any significant bugs and all the features I plan on implementing for the first rev are there. I'll have a patch ready for submission in a day or so. Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- -- Troy Benjegerdes'da hozer'[EMAIL PROTECTED] Somone asked me why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] undefined instruction handling to fix for ARM
After some significant debugging I found the problem with GDB on the
target side.
The instruction translation was not correctly executing undefined
instructions per section 3.13.1 of the ARM Architecture Reference
Manual. Using the attached patch, the target side GDB as well as kernel
side ptrace() with software breakpoints execute correctly and report
exceptions to the correct vector.
Thanks,
Jason.
? .pc
? patches
Index: Changelog
===
RCS file: /sources/qemu/qemu/Changelog,v
retrieving revision 1.115
diff -u -r1.115 Changelog
--- Changelog 30 Apr 2006 21:28:35 - 1.115
+++ Changelog 2 May 2006 20:14:20 -
@@ -8,6 +8,8 @@
- Solaris port (Ben Taylor)
- Preliminary SH4 target (Samuel Tardieu)
- VNC server (Anthony Liguori)
+ - Fix undefined instruction handling
+for gdb and soft stepping (Jason Wessel)
version 0.8.0:
Index: target-arm/translate.c
===
RCS file: /sources/qemu/qemu/target-arm/translate.c,v
retrieving revision 1.41
diff -u -r1.41 translate.c
--- target-arm/translate.c 9 Apr 2006 14:38:57 - 1.41
+++ target-arm/translate.c 2 May 2006 20:14:20 -
@@ -1589,6 +1589,15 @@
case 0x5:
case 0x6:
case 0x7:
+/* Check for undefined extension instructions
+ * per the ARM Bible IE:
+ * 0111
+ */
+sh = (0xf 20) | (0xf 4);
+if (op1 == 0x7 ((insn sh) == sh))
+{
+goto illegal_op;
+}
/* load/store byte/word */
rn = (insn 16) 0xf;
rd = (insn 12) 0xf;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu elf_ops.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 20:54:12 Modified files: . : elf_ops.h Log message: fixed memory leak CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/elf_ops.h.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug report : kqemu and self-writing code
To clarify the current behaviour of kqemu and QEMU with self-writing
code, the following table can be useful:
Supported feature QEMUkqemu
CS.limit no yes
NX bit yes (x86_64 only) no
So you can understand now why in some cases QEMU or kqemu does not seem
to give what you expect. Fixing both issues is of course possible but it
is not my priority yet.
Fabrice.
G Portokalidis wrote:
I had a similar problem, but only when not using kqemu.
When using a stack overflow exploit, the shellcode provided only
executes when using kqemu. I can attribute this to either the
shellcode being in a different location (maybe someone can clarify
this, is qemu using a different memory layout e.g. stack is located in
a different virtual address), or qemu does not translate the shellcode
located in the stack and instead causes a memory fault (again i have
no idea why this should be the case).
When using kqemu the shellcode executes normally.
I did not have any time to investigate the reasons, but i have a hunch
it is the probably the translation.
If anyone knows what the problem is, i would be glad to write a patch.
On 02/05/06, Kevin F. Quinn [EMAIL PROTECTED] wrote:
Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard [EMAIL PROTECTED] wrote:
Are you sure that the bug is really in kqemu ? It is possible that
your guest kernel implements a security system which prevents self
modifying code using segment limits which QEMU does not check (but
kqemu checks them !).
Regards,
Fabrice.
Even Rouault wrote:
Guest OS : Linux 2.6.15-1.2054_FC5 i686 (Fedora Core 5 i386)
Host OS: Linux 2.6.12-10-amd64-k8 #1 x86_64 (Ubuntu 5.10 amd64)
QEMU Version : today CVS compiled with kqemu support
KQEMU : 1.3.0pre6
Binary used : qemu-system-x86-64 (so kqemu user-mode is used)
I'm running the simple C code attached. With kqemu user-mode, this
fails (sigsegv) with the following warning in dmesg :
audit(1146505373.813:12): avc: denied { execheap } for pid=1860
comm=selfmodifying scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
Erreur de segmentation
Without kqemu enabled, it runs fine.
#define _XOPEN_SOURCE 600
#include sys/mman.h
#include unistd.h
#include stdlib.h
#include stdio.h
int main(int argc, char** argv)
{
int pagesize = getpagesize();
unsigned char* addr = NULL;
posix_memalign((void**)addr, pagesize, pagesize);
mprotect(addr, pagesize, PROT_WRITE | PROT_READ | PROT_EXEC);
addr[0] = 0x8b; addr[1] = 0x44; addr[2] = 0x24; addr[3] =
0x04; /* mov0x4(%esp),%eax */ addr[4] = 0x83; addr[5] = 0xc0;
addr[6] = 0x01; /* add$0x1,%eax */ addr[7] = 0xc3; /* ret */
printf(10+1=%d\n, ((int (*)(int))addr)(10));
free(addr);
return 0;
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
--
Kevin F. Quinn
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/slirp ip.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 21:09:02 Modified files: slirp : ip.h Log message: 32 KB packet handling (Ed Swierk) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/slirp/ip.h.diff?tr1=1.1tr2=1.2r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw mips_r4k.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:18:28 Modified files: hw : mips_r4k.c Log message: performance boost (on P4 hosts at least, rdtsc is a _very_ bad random generator) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.15tr2=1.16r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] MIPS interrupt handling
I just looked at the MIPS file target-mips/op_helper.c and I don't understand why IRQs need to be handled in op_helper.c:do_mtc0() with reg = 12. IMHO, the corresponding code should be deleted because the TB is forced to terminate after mtc0 so that the IRQs can be handled in the main loop in cpu-exec.c. Moreover, clearing CPU_INTERRUPT_HARD in do_mtc0() is almost surely a bug ! Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:52:36 Modified files: . : Makefile.target Log message: correct qemu-system-mipsel naming CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.106tr2=1.107r1=textr2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/hw mips_r4k.c
Fabrice Bellard wrote: CVSROOT: /sources/qemu Module name: qemu Branch: Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:18:28 Modified files: hw : mips_r4k.c Log message: performance boost (on P4 hosts at least, rdtsc is a _very_ bad random generator) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.15tr2=1.16r1=textr2=text Does this really provide a measurable performance improvement? Real hardware simply increments cp0_random together with the cycle counter, this is randomized enough for TLB entry replacement. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] ppc32 linux host compile failure
Can someone educate me on what might be wrong here? [EMAIL PROTECTED]:/scratch/troy/qemu-cvs-patched$ gcc-3.4 --version gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) [EMAIL PROTECTED]:/scratch/troy/qemu-cvs-patched$ ld --version GNU ld version 2.16.91 20060118 Debian GNU/Linux make[1]: Entering directory `/scratch/troy/qemu-cvs-patched/i386-user' gcc-3.4 -g -Wl,-T,/scratch/troy/qemu-cvs-patched/ppc.ld -o qemu-i386 elfload.o main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o vm86.o libqemu.a gdbstub.o -lm /usr/bin/ld: qemu-i386: Not enough room for program headers (allocated 8, need 9) /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[1]: *** [qemu-i386] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
