[Qemu-devel] On-demand taint tracking
Hi Qemu developers,
I have implemented a whole-system taint tracking system on Qemu. But the
performance overhead is big. Now I want to optimize it by performing
on-demand taint tracking. The idea is that Qemu runs in virtualization
mode most of time (running with kqemu), and switches to emulation mode
to propagate taint information when necessary. When taint information is
not propagating for a while, I put Qemu into virtualization mode again.
Before I put it into virtualization mode, I disable the tainted pages by
removing their PG_PRESENT flags. So once kqemu accesses one of these
pages, the page fault handler gets called, and qemu gets control.
I have written something for this, but it does not work. The guest OS
crashes immediately when I put Qemu into virtualization mode. Kqemu does
not raise page fault before the target OS crashes.
I list part of my code below. Can someone give any hints of what I did
wrong here?
/*this function disable all the tainted pages, and put it
into virtualization mode */
int switch_e2v()
{
int i;
uint32_t pte;
//enable the pages
for(i=0; ipte_addr) continue;
//if this page is tainted, I get its pte, and clear
//its PG_PRESENT flag
pte = ldl_phys(page->pte_addr);
pte &= ~PG_PRESENT_MASK;
// I set the avail bits to all 1s, so that I know this
//page is different from those actually not present
pte |= 0xe00;
stl_phys_notdirty(page->pte_addr, pte);
}
emulation_mode = 0; //indicate we are entering virtualization mode
return 0;
}
Any comments are highly appreciated!
Thanks a lot,
Heng
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
--- Pierre d'Herbemont <[EMAIL PROTECTED]> wrote:
Hi Pierre,
Thanks for your reply - please see comments inserted
below:
> Hi Ilya!
>
> On 23 févr. 07, at 21:32, Ilya Shar wrote:
>
> > I'm running i386-darwin-usrer on i386 and some
> apps
> > (Safari browser) crash because cmpxchg8b attempts
> to
> > wrie to a qemu-allocated page which is readable
> but
> > write-protected. When I comment out mprotect in
> > exec.c
>
> Are you sure it does Safari does crash because of
> that call? I have
> the Apple Bug Reporter which complains about the
> fact that qemu gets
> a EXC_BAD_ACCESS, but then I get this error:
> qemu: Unsupported mach syscall: -61(0xffc3) (=
> semaphore_signal_trap)
> or
> qemu: Unsupported mach syscall: -33(0xffdf) (=
> syscall_thread_switch)
>
> To fix this we have to implement those syscalls.
>
Sure. At first I was hitting unsupported mach
syscalls, so I modified darwin-user/syscall.h
according to
/Developer/SDKs/MacOSX10.3.9.sdk/usr/include/mach/syscall_sw.h
:
$ diff syscall.c syscall.c.orig
458,465d457
< case -33:
< DPRINTF("semaphore_signal_trap(0x%x)\n",
arg1);
< ret = semaphore_signal_trap(arg1);
< break;
< case -34:
< DPRINTF("semaphore_signal_all_trap(0x%x)\n",
arg1);
< ret = semaphore_signal_all_trap(arg1);
< break;
471,474d462
< case -37:
< DPRINTF("semaphore_wait_signal_trap(0x%x,
0x%x)\n", arg1, arg2);
< ret = semaphore_wait_signal_trap(arg1,arg2);
< break;
With this Sfari went past the unsupported call -33 and
now stops in call -61 (syscall_thread_switch). Can I
just modify syscalls.c in a similar way to fix it?
But a really alarming thing happens before it gets
there. If my ethernet cable is not plugged in,
cmpxchg8b write to a nonwritable page brings my system
down. I suppose it happens in somewhere in the
drivers.
...
>
> I think the idea behind the mprotect is to make sure
> that any changes
> to this pages gets monitored, and that the tb can be
> invalidated if
> the code was modified (self modify-ing code).
That makes sense. Still I am not sure why cmpxchg8b
causes problems.
Thanks!
Ilya
>
> Pierre.
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] armv6 support
On Friday 23 February 2007 20:09, Rodrigo Vivi wrote: > Hi all, > > Is there someone working on armv6 support? > I'm very interested to help this development... I already have ARMv6 and ARMv7 implemented, but am unable to release the code. See: http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00202.html We (CodeSourcery) are negotiating with ARM to have this restriction lifted, but it's slow going. If you want to see ARMv6 support in QEMU please contact ARM directly and encourage them to sort the legal issues out. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Page protection and i386 cmpxchg8b
Hi Ilya! On 23 févr. 07, at 21:32, Ilya Shar wrote: I'm running i386-darwin-usrer on i386 and some apps (Safari browser) crash because cmpxchg8b attempts to wrie to a qemu-allocated page which is readable but write-protected. When I comment out mprotect in exec.c Are you sure it does Safari does crash because of that call? I have the Apple Bug Reporter which complains about the fact that qemu gets a EXC_BAD_ACCESS, but then I get this error: qemu: Unsupported mach syscall: -61(0xffc3) (= semaphore_signal_trap) or qemu: Unsupported mach syscall: -33(0xffdf) (= syscall_thread_switch) To fix this we have to implement those syscalls. //mprotect(g2h(page_addr), qemu_host_page_size, // (prot & PAGE_BITS) & ~PAGE_WRITE); I can proceed further. I would guess mprotect is there for a reason so it doesn't seem like a good solution, besides the runs get substantially slower without mprotect. Is there a solution to this problem or a way to better understand what is going on? I think the idea behind the mprotect is to make sure that any changes to this pages gets monitored, and that the tb can be invalidated if the code was modified (self modify-ing code). Pierre. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] make install qemu-system-x86
Could make install do a "qemu-system-x86" and then symlink the "qemu" name to whatever the host platform happens to be? (So if you build qemu on x86-64 then qemu points to "qemu-system-x86_64"? Or if you build the sucker on a PPC system...) The relevant code seems to be is in Makefile.target, line 50 or so: # system emulator name ifdef CONFIG_SOFTMMU ifeq ($(TARGET_ARCH), i386) QEMU_SYSTEM=qemu$(EXESUF) else QEMU_SYSTEM=qemu-system-$(TARGET_ARCH2)$(EXESUF) endif else QEMU_SYSTEM=qemu-fast endif And I have no idea what "qemu-fast" is so I'm keeping my hands off. (Something to do with kqemu?) I previously thought it was special casing whatever the host platform is, but I see it's currently special casing i386 specifically. Rob P.S. I think the new link to be called "qemu-system-x86" rather than "qemu-system-i386" since i386 is a specific model of x86 processor and we haven't got qemu-system-armv4 and qemu-system-armv5, although if somebody wanted to make a way to specify that I'd be pretty happy. (Periodically the question comes up "how do I do a 586 build" and although it's easy enough to cross-compile for that, it's hard to come up with a test environment without plugging in actual hardware. "It runs on my laptop" is no guarantee, my laptop's a Pentium M...) However, I realize there's currently a "qemu-i386" in user emulation... -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Page protection and i386 cmpxchg8b
Hi, I'm running i386-darwin-usrer on i386 and some apps (Safari browser) crash because cmpxchg8b attempts to wrie to a qemu-allocated page which is readable but write-protected. When I comment out mprotect in exec.c //mprotect(g2h(page_addr), qemu_host_page_size, // (prot & PAGE_BITS) & ~PAGE_WRITE); I can proceed further. I would guess mprotect is there for a reason so it doesn't seem like a good solution, besides the runs get substantially slower without mprotect. Is there a solution to this problem or a way to better understand what is going on? Thanks, Ilya Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] armv6 support
Hi all, Is there someone working on armv6 support? I'm very interested to help this development... Thanks, Rodrigo Vivi. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: >11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a 6c6f 3d 6c6f 0a 65746830 3d 65746830 0a or, of course (duh, I should have noticed, although I'm not sure this can help), lo=lo\n eth0=eth0\n ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] syscall readahead
Kirill A. Shutemov wrote: > Patch from Debian patchset in the attachment > --- linux-user/syscall.c.orig 2006-11-05 07:07:19.0 +0200 > +++ linux-user/syscall.c 2006-11-05 07:07:25.0 +0200 > @@ -3947,7 +3956,8 @@ long do_syscall(void *cpu_env, int num, > ret = get_errno(gettid()); > break; > case TARGET_NR_readahead: > -goto unimplemented; > +ret = get_errno(readahead((int)arg1, (off64_t)arg2, (size_t)arg3)); > +break; arg2 is a (off64_t *), I figure it needs locking. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] [REPOST] Simplily linux-user/path.c
Kirill A. Shutemov wrote:
> Fixed version of the patch in the attacment. Please, comment.
[snip]
> /* Look for path in emulation dir, otherwise return name. */
> const char *path(const char *name)
> {
> +char *newname = (char *) alloca(strlen(pref)+strlen(name)+1);
> +struct stat buf;
> /* Only do absolute paths: quick and dirty, but should mostly be OK.
> Could do relative by tracking cwd. */
> -if (!base || name[0] != '/')
> - return name;
> +if (!pref || name[0] != '/')
> +return name;
> +
> +strcpy(newname,pref);
> +strcat(newname,name);
>
> -return follow_path(base, name) ?: name;
> +return stat(newname,&buf) ? name : strdup(newname);
> }
This leaks memory allocated by strdup(). Also, the old code tries to
avoid syscalls by memorizing the paths. AFAICS we should do some
caching here.
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get 1280x1024 display from guest running Xorg?
Thanks for the feedback. Since I do not wish to be involved in a great battle (as you so nicely put it) I'll stick with VMware (sigh). J On Wednesday 21 February 2007 15:05, Robin Atwood wrote: > On Wednesday 21 Feb 2007, Julian Seward wrote: > > (replying off list) > > > > So you have Solaris 10 (x86 ?) running on qemu-0.9 ? Is it stable? > > Does it work? I have it running on vmware-5.5.3 but would prefer to > > move to running it on qemu if possible; however I've had mixed > > results with qemu in the past and don't want to spend loads of time > > on failed attempts to get it to work. Hence the question. > > It was a great battle to install but now it is stable. Do the following > things: > 1. install from the DVD image > 2. Use the text console install > 3. At the end of the install, backup the image file *before* the first > reboot 4. If during the first boot of the image, you get a segfault, > restore and try again until you get to a prompt. Ignore any service > failures. (the filesystem seems prone corruption at the first boot.) > 5. If you have problems caused by damaged files, re-install choosing > the "Update" option: this will restore the damaged files. > > After that, I was able to boot reliably into X. However, the filesystem > seems very fragile if not shut down cleanly, so take regular backups! > > HTH > -Robin. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QCOW image corruption under QEMU 0.9.0
Greetings I got some error messages shortly after booting a Debian guest under QEMU 0.9.0. I did not annotate those, but they made me believe there could be disk access problems, and if fact something weird happened to one of the disk images (this was using two images, for hda and hdb): After shutting down the guest, I inspected its image files with qemu-info, which reported for hda image: nisaba.hda.qcow file format: raw virtual size: 4.3G (4596273152 bytes) disk size: 4.3G but hda was supposed to have a virtual size of approximately 20 GB, QCOW2 format and a saved snapshot... The hdb image still seems OK: image: nisaba.hdb.qcow file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 216M cluster_size: 4096 Snapshot list: IDTAG VM SIZEDATE VM CLOCK 1 2007021766M 2007-02-17 05:58:40 46:06:17.193 I'll keep a copy of the damaged image in case someone competent on qemu and qcow wishes to inspect it, but in case this may be suggestive: I noticed that the only non-zero bytes until byte 12288 (where a first 'more random' sequence starts) are: byte 4102: 0x20 4110: 0x30 4118: 0x40 ... and so on, until 4206: 0xf0 4221-4222: 0x0110 4229-4230: 0x0120 4237-4238: 0x0130 4245-4246: 0x0140 4252-4254: 0xd547b0 4260-4262: 0xd547c0 ... 8180-8182: 0xd56660 8188-8190: 0xd56670 11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a Unvortunately I don't have an older copy of the hda image with which to compare this broken one. In any case I have been running, in the same host, several 32-bit guests with Debian and one with Windows XP, almost without any problems, first under QEMU 0.8.2 and since February 11 under QEMU 0.9.0 (with some images then migrated from QCOW to QCOW2). Details on the configuration: Host: AMD Athlon 64 3500+ (HP dx5150 MT) with Ubuntu 6.06 LTS, kernel 2.6.15-28-amd64-k8. VDE: 'backported' (just rebuilding the package) from Debian testing's vde 1.5.11-1. QEMU: 0.9.0, configured with --cc=gcc-3.4 --enable-alsa kqemu: 1.3.0pre11 Guest: Debian Etch (32-bit), with kernel 2.6.18-k7 (if I remember correctly); / was on hda, the failed image file; /tmp and swap on hdb, the surviving image. QEMU was invoked with vdeq qemu-system-x86_64 \ -kernel-kqemu \ -pidfile nisaba.pid \ -m 192 \ -std-vga \ -net nic,vlan=0,model=rtl8139,macaddr=4A:4D:23:00:00:01 \ -net vde,vlan=0,sock=/var/run/vde/tap-vde-1.ctl \ -hda nisaba.hda.qcow -hdb nisaba.hdb.qcow Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
