[Qemu-devel] A couple of question

[Qemu-devel] A couple of question

[Balazs Attila-Mihaly (Cd-MaN)]

Hello all.

First of all I want to congratulate everybody on this list for the wonderful job s/he is doing. Qemu is the best Open Source emulator out there (and it is fast ;-) ). I'm using Qemu to build an automated malicious code analysis system and as such I would like to make some modifications:

-create an option to dump all the traffic coming out of an interface in a tcpdump (pcap) file. I've managed to implement this (and if anyone is interested, I can provide a diff against the latest CVS, the changes being very localized and no more than 100 lines), however I have my doubts: I do the traffic logging in the qemu_send_packet function, which refers to VLAN's not to NIC's. 

Because of this I associated the structures needed for the dump (like the output file handle) with the VLANState structure, however maybe it would be more appropiate to associate it with a NICInfo structure (because it makes - usually - more sense to dump the traffic from one NIC rather than one VLAN imho), but I couln't find (a) any method to get the appropiate NICInfo structure inside of qemu_send_packet or (b) find a different function which has access to NICInfo.

My first question would be: am I hooking at the right point?

-modified the breakpoints to be stored in a hash structure (like this breakpoints[256][1024]) where the hash key is given by the least significant byte of the breakpoint address.  I've done this because I intend to put a lot (and I mean a lot :-) ) of breakpoints. I also modified the watchpoint code in a similar manner. again, if you are interested I can provide a diff against the CVS. 

-Created an option to dump the sectors where there been writes to a file / console / etc (whatever qemu_chr_open supports). I've done this because after the execution of the malicious code I want to quickly asses which sectors have been written (again, if somebody would find something like this usefull, I can provide diffs). An other option would have been to create a difference disk over the basic image and take the list of sectors from the difference image (which obviously are present because they have been modified). However this approach has the drawback that it can't be used with snapshots. Specifically, I would like to do something like this

[ base image (with a snapshot for quick startup) ] <-- [ diff image ] <-- Qemu

However it seems that Qemu can read the snapshot only from the last image in the chain (diff image in the example). How hard is it to make this work with an arbitrary image from the chain? One obvious thing which needs to be done is making sure that the snapshot ID's / tag names are unique across the whole chain, but other than that how easy is to make this happen?

-Also created an option to dump the program state (ie. variables from the stack) at certain points in the execution. My solution is the following:

1. Add a list of breakpoints right before main_loop(); (to the first_cpu)
2. In the main_loop function where it says "if (ret == EXCP_DEBUG) {", I added a function call to check if it is one of my breakpoints. 
3. If so I log the data and return 1, otherwise 0. I check the return value and if it's 1, I do a "vm_start();" (this all is done after "vm_stop(EXCP_DEBUG);")

However there seem to be a flaw in this approach and the code seem to enter in an infinite cycle. My theory is the following (which I hope somebody can confirm or prove wrong);

-the execution hits the TB which contains the 0xCC (int 3) corresponding to the breakpoint
-the int 3 is catched (before the instruction is executed) and control is transferred back to the main loop
-the logging procedure gets called
-when resuming the execution is started at the TB (because the instruction did not execute yet and needs to be executed), but because it contains a 0xCC, it again is thrown back to the main loop and so on.

If my theory is right, then the breakpoint must be removed (at least temporarily) for the execution to continue. However there is no guarantee that I can get back control in timely fashion (for example at the next instruction) to insert the breakpoint back because of TB chaining, plus I'm concerned that such an add / remove would very quickly trash the TB cache. My questions would then be:

1. Is my assumption of what's going on correct? and
2. what can I do? for example one thing I though of was to set some flag when such a breakpoint is occured to ignore the next int 3 in the exception handler which catches it and gives back the control to the main loop. An other thing would be to dynamically patch the TB and replace 0xCC (int 3) with 0x90 (NOP). Of course this has the problem that to patch the TB must be located first and also the problem of when can the "back" patching occur.


PS. I'm willing to provide the code for this part also (if somebody is interested), however it's still very alpha (it doesn't even work yet , as you can see from my questions :-))

PPS. If there are some coding guidelines / formatting standards my code should adhere to before it can be accepted, please point me in the right direction.

PPPS. I can't really debug Qemu (GDB seems to jump all over the place). I tried to build it statically (as per an advice given in the mailing list some time ago), but if I do 

./configure --target-list=i386-softmmu --static
make

I end up with a bunch of linker errors, like the following:

/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/librt.a(aio_cancel.o): In function `aio_cancel64': (.text+0x2f): undefined reference to `pthread_mutex_lock'
...
/usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/librt.a(aio_misc.o): In function `handle_fildes_io': (.text+0x737): undefined reference to `pthread_mutex_lock'
...
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_bases': (.text+0x21c): undefined reference to `pthread_create'

What am I missing? (probably something very obvious since I'm relatively new to Linux)

Best regards, sorry for taking up so much of you valuable inbox space ;-), and thank you in advance for your time,
Attila-Mihaly Balazs




      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

Re: [Qemu-devel] A couple of question

[C.W. Betts]

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

It looks like you are missing the pthread library.  What might be  
happening is that the pthread library is installed, but qemu is not  
linking to it for some odd reason.  Maybe it's looking for a static  
version of it that isn't on your Hard Drive?
On Tuesday, June 5, 2007, at 03:20 PM, Balazs Attila-Mihaly ((Cd-MaN))  
wrote:

> PPPS. I can't really debug Qemu (GDB seems to jump all over the  
> place). I tried to build it statically (as per an advice given in the  
> mailing list some time ago), but if I do
>
> ./configure --target-list=i386-softmmu --static
> make
>
> I end up with a bunch of linker errors, like the following:
>
> /usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/ 
> librt.a(aio_cancel.o): In function `aio_cancel64': (.text+0x2f):  
> undefined reference to `pthread_mutex_lock'
> ...
> /usr/lib/gcc/i486-linux-gnu/3.4.6/../../../../lib/librt.a(aio_misc.o):  
> In function `handle_fildes_io': (.text+0x737): undefined reference to  
> `pthread_mutex_lock'
> ...
> /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_eh.a(unwind-dw2-fde-glibc.o):  
> In function `__register_frame_info_bases': (.text+0x21c): undefined  
> reference to `pthread_create'
>
> What am I missing? (probably something very obvious since I'm  
> relatively new to Linux)
>
> Best regards, sorry for taking up so much of you valuable inbox space  
> ;-), and thank you in advance for your time,
> Attila-Mihaly Balazs
>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 207 bytes --]

Re: [Qemu-devel] A couple of question

[Sunil Amitkumar Janki]

C.W. Betts wrote:
> It looks like you are missing the pthread library.  What might be 
> happening is that the pthread library is installed, but qemu is not 
> linking to it for some odd reason.  Maybe it's looking for a static 
> version of it that isn't on your Hard Drive?

I have been seeing these kinds of errors lately building software on MIPS,
even when they build fine on x86. My solution to these kinds of errors
was to include "-lpthread" somewhere in the CFLAGS or patch the source
code to include this linker flag. I haven't seen it with QEMU though.

Re: [Qemu-devel] A couple of question

[Jan Marten Simons]

Balazs Attila-Mihaly (Cd-MaN) schrieb:
> Hello all.
>
> First of all I want to congratulate everybody on this list for the wonderful job s/he is doing. Qemu is the best Open Source emulator out there (and it is fast ;-) ). I'm using Qemu to build an automated malicious code analysis system and as such I would like to make some modifications:
>   

You're not the first doing so, if you don't know: 
http://www.few.vu.nl/argos/ perhaps you can base your work on argos or 
just contribute to this project.

regs.
Jan