Re: [PATCH] plugins: add plugin API to read guest memory

[Rowan Hart <rowanbhart@gmail.com>]

Alex,

Thanks for the additional information.

>>
>> A key aspect of what you propose here, is that the memory may have
>> changed during the write time, and when you read it, while what we
>> propose guarantees to track every change correctly.
>>
>> It's not a bad thing, and both API are definitely complementary. When
>> talking to Alex, he was keen to add a global read_memory API (like you
>> propose), after we merge the first one.
>>
>> @Alex: any thought on this?
> 
> I'd like to get the memory callback API merged first - mostly because
> that is the API that will absolutely reflect what was loaded or stored
> to a given memory location. For precise instrumentation that is the one
> to use.
> 
> However I agree the ability to read the state of memory outside of loads
> and stores is useful especially for something like this. It's not
> unreasonable to assume the memory state of arguments going into a
> syscall isn't being messed with and it is easier to track pointers and
> strings with a more general purpose API.
> 

I agree, I considered the absolute load/store question and poked around the
code a bit, but I didn't find what looked like a solid way to either:

A) Ensure that all writes are flushed before the read happens (which sounds
like a hefty performance penalty anyway) or
B) Check whether there are outstanding writes and return an error

It sounds like essentially use cases where that level of per-insn write
granularity matters should utilize your upcoming API instead of this one, and I
will add a call-out to the doc of this one to alert users of the potential pitfall.

>>>       qemu_plugin_register_vcpu_syscall_cb(id, vcpu_syscall);
>>>       qemu_plugin_register_vcpu_syscall_ret_cb(id, vcpu_syscall_ret);
>>>       qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
> 
> There was someone on IRC looking to trace system calls in system mode
> (by tracking the syscall instruction and reading the registers at the
> time). I wonder if we could make this plugin do the right thing in both
> modes?
> 

Cool! I think this should be doable.

-Rowan