Re: [Qemu-devel] Binary Translation hooking - reading registers

["felix.matenaar@rwth-aachen" <felix.matenaar@rwth-aachen.de>]

On 02/13/2011 06:38 AM, Mulyadi Santosa wrote:
> Hi....
>
> On Sun, Feb 13, 2011 at 10:48, felix.matenaar@rwth-aachen
> <felix.matenaar@rwth-aachen.de> wrote:
>> To achieve my goal, it is necessary being able reading actual register
>> configuration like eax when a ret hook is called to get a function
>> return value. So my question is how I can do this. Are there already
>> some functions which generate code to update the cpu environment? If
>> not, is there anything you can point me towards for adding support?
> I think you should look into the tracing infrastructure that is
> gradually added to Qemu. I forgot the URL that provide the patch
> (since I am not sure whether it's fully merged with mainline). Please
> check this list archieve...
>
> NB: You're talking about qemu system emulation,right? not the user
> mode emulation, I assume? Because you said "executed in one step" (or
> something like that). AFAIK, although Qemu does lazy evalution, but
> for general registers it should be always updated. The one that gets
> lazy evalution for example is eflags.
>

Yes I am talking about full system emulation (i386).

Tracing infrastructure may be suitable for my needs in the future but I
think that my instrumentation patches which are already added as far as
I need it have a bit less overhead.

To be more specific on my env update problem, here an example:

push ebp
mv esp,ebp
/* do something */
call 0xfoo
test eax,eax
/* do something */
ret

The first line is the start of a block. What I did was adding a
gen_helper_instrument_call in the 'call' opcode cases in disas_insn()
which will call my analysis code to examine from where the call is
launched, where it will go and what is the address we will return to
after (in this case regarding to call 0xfoo).
Because in this case, usage of tcg_const_i32(pc_start) and providing
CPU_T[0] as parameters to my generated helper, I can provide all three
values. But what I would _assume_ is that after
gen_helper_instrument_call is executed, env->eip would point towards
'call 0xfoo', but it points to 'push ebp'. Thats why I am confused if I
can trust the values in env to gain more information about the current
register values of the guest machine. This particular case is indeed not
a problem since I can provide all parameters to
gen_helper_instrument_call here but there are cases where I would like
to read e.g. esp for keeping an analysis shadow stack up to date or
reading return values by examining eax when my ret hook is called.

This is my call immediate handler:

void helper_call_im_protected(target_ulong src_eip, target_ulong
new_eip, int next_eip){
  if (!(new_eip & 0x80000000) ){
    /* env->eip == src_eip will evaluate to 0 if 'call' opcode was not
at the beginning of the translation block*/
    analysis_examine_call(src_eip,new_eip,next_eip);
  }
}

Here my hook inserting in disas_insn:
case 0xe8: /* call im */
    {   
        /* some code */
        gen_movtl_T0_im(next_eip);
        gen_push_T0(s);

        /* will call helper_call_im_protected when call opcode is
executed */
        gen_helper_call_im_protected(tcg_const_i32(pc_start),
                                     tcg_const_i32(tval),
                                     cpu_T[0]);
        gen_jmp(s, tval);
    }   

Hope you understand.