[Qemu-devel] Qemu memory operations

[Qemu-devel] Qemu memory operations

[Prathmesh Kallurkar]

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

Hello friends,
I intend to use Qemu to generate a memory trace for the execution of a x86
guest operating system.

According to tcg
wiki<http://wiki.qemu.org/Documentation/TCG/backend-ops#Load.2FStore>page,
Qemu uses a handful of helpers to generate load/stores to the
target(guest) memory.
This list of instructions is tcg_gen_qemu_ld8s/u, tcg_gen_qemu_ld16s/u,
tcg_gen_qemu_ld32s/u, tcg_gen_qemu_ld64. (We have a similar set for store
instructions).
I am trapping all calls to the above functions in the
target-i386/translate.c file

However, I am still missing load/stores of certain instructions like
cmp ecx, [r12+0x4]
mov r10b, [r13+0x0]
mov byte [rax+0xf0000], 0x0
mov byte [rax+rdx], 0x0

Questions ::
1) Can someone please point to other load/store points (direct or indirect)
that I am missing ??
2) Does qemu provide a single entry point function for accesses to guest
memory (like guest_read()) which can be instrumented for tracing all loads
from the guest memory ???
3) Can somebody please point to a good documentation where I can understand
how qemu maintains the state of the guest memory ??

Thanks in advance.


Regards,
Prathmesh Kallurkar <http://www.cse.iitd.ac.in/%7Eprathmesh>

[-- Attachment #2: Type: text/html, Size: 1308 bytes --]

Re: [Qemu-devel] Qemu memory operations

[Prathmesh Kallurkar]

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

Sorry friends for the misleading instructions in the previous mail.

cmp ecx, [r12+0x4]
mov r10b, [r13+0x0]
mov byte [rax+0xf0000], 0x0
mov byte [rax+rdx], 0x0

It seems all the above instructions are getting covered with the
tcg_gen_ld/st helpers.

But now I have stumbled upon another problem :
I initially thought that all the interactions with the guest memory happen
through the helper instructions in the translate.c file.
However, I found that the helper functions for some instructions like
*cmpxcgh8b
*and* cmpxchg16b* are actually accessing guest memory.

So, does it mean there are more than one entry points for reading guest
memory.
Can some one please explain how are the *ldq and stq* instructions
translated to access the guest memory ??

Thanks in advance.


Regards,
Prathmesh Kallurkar

[-- Attachment #2: Type: text/html, Size: 1045 bytes --]

Re: [Qemu-devel] Qemu memory operations

[Blue Swirl]

On Tue, Aug 14, 2012 at 11:58 AM, Prathmesh Kallurkar
<prathmesh.kallurkar@gmail.com> wrote:
> Sorry friends for the misleading instructions in the previous mail.
>
> cmp ecx, [r12+0x4]
> mov r10b, [r13+0x0]
> mov byte [rax+0xf0000], 0x0
> mov byte [rax+rdx], 0x0
>
> It seems all the above instructions are getting covered with the
> tcg_gen_ld/st helpers.
>
> But now I have stumbled upon another problem :
> I initially thought that all the interactions with the guest memory happen
> through the helper instructions in the translate.c file.
> However, I found that the helper functions for some instructions like
> cmpxcgh8b and cmpxchg16b are actually accessing guest memory.
>
> So, does it mean there are more than one entry points for reading guest
> memory.
> Can some one please explain how are the ldq and stq instructions translated
> to access the guest memory ??

I suppose target-i386/translate.c:5245 handles mov mem, reg case even
for 64 bit. But QEMU is not a very nice platform for memory access
instrumentation because of internal TLBs and code generation.

There have been some discussions about tracking guest memory accesses
before, please check the list archives.

>
> Thanks in advance.
>
>
> Regards,
> Prathmesh Kallurkar

Re: [Qemu-devel] Qemu memory operations

[Steven]

Hi, Prathmesh
I am working on getting the guest memory trace too. You said you have
trapped the guest memory access for most instructions. I have three
questions.
1. Did you get the guest physical address for the load/store instructions?
2. The code you pasted seems translated code. The number of input code
could be smaller than this. So don't you think we should trap the
input code, instead of the translated code?

> cmp ecx, [r12+0x4]
> mov r10b, [r13+0x0]
> mov byte [rax+0xf0000], 0x0
> mov byte [rax+rdx], 0x0

3. Suppose that I have a tb block which has only one instruction to be
translated
            mov    0x4(%esp),%edx
    I tried to calculate the guest physical address of 0x4(%esp) in
the above in the function of disas_insns(...), is this possible? Or do
you have any other solutions?
Thanks.


Steven

On Sun, Aug 12, 2012 at 12:31 PM, Prathmesh Kallurkar
<prathmesh.kallurkar@gmail.com> wrote:
> Hello friends,
> I intend to use Qemu to generate a memory trace for the execution of a x86
> guest operating system.
>
> According to tcg wiki page, Qemu uses a handful of helpers to generate
> load/stores to the target(guest) memory.
> This list of instructions is tcg_gen_qemu_ld8s/u, tcg_gen_qemu_ld16s/u,
> tcg_gen_qemu_ld32s/u, tcg_gen_qemu_ld64. (We have a similar set for store
> instructions).
> I am trapping all calls to the above functions in the
> target-i386/translate.c file
>
> However, I am still missing load/stores of certain instructions like
> cmp ecx, [r12+0x4]
> mov r10b, [r13+0x0]
> mov byte [rax+0xf0000], 0x0
> mov byte [rax+rdx], 0x0
>
> Questions ::
> 1) Can someone please point to other load/store points (direct or indirect)
> that I am missing ??
> 2) Does qemu provide a single entry point function for accesses to guest
> memory (like guest_read()) which can be instrumented for tracing all loads
> from the guest memory ???
> 3) Can somebody please point to a good documentation where I can understand
> how qemu maintains the state of the guest memory ??
>
> Thanks in advance.
>
>
> Regards,
> Prathmesh Kallurkar

Re: [Qemu-devel] Qemu memory operations

[Prathmesh Kallurkar]

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

1. Did you get the guest physical address for the load/store instructions?
No, I am getting the guest virtual address for the load and store
instructions.



> 2. The code you pasted seems translated code. The number of input code
> could be smaller than this. So don't you think we should trap the
> input code, instead of the translated code?
>

I am trapping the guest code and NOT the translated code.  For this I am
transferring the guest instruction bytes (using ldub_code) to a remote
disassembler and then inspecting the instruction.


> > cmp ecx, [r12+0x4]
> > mov r10b, [r13+0x0]
> > mov byte [rax+0xf0000], 0x0
> > mov byte [rax+rdx], 0x0
>

The above instructions are instructions of a i386 guest system.

>
> 3. Suppose that I have a tb block which has only one instruction to be
> translated
>             mov    0x4(%esp),%edx
>     I tried to calculate the guest physical address of 0x4(%esp) in
> the above in the function of disas_insns(...), is this possible? Or do
> you have any other solutions?
>

Sorry but seems I have not considered this case. See, I am just trapping
the calls to tcg_gen_qemu_ld/st and then checking my coverage by inspecting
the decoded instructions given by my disassembler. I flag an error when I
receive an instruction which was supposed to contain a load/store
instruction but  I could not trace one. I will definitely see what I get
for *mov    0x4(%esp),%edx*


-- 
Regards,
Prathmesh Kallurkar <http://www.cse.iitd.ernet.in/%7Eprathmesh>

[-- Attachment #2: Type: text/html, Size: 2149 bytes --]

Re: [Qemu-devel] Qemu memory operations

[Steven]

On Wed, Aug 15, 2012 at 4:57 AM, Prathmesh Kallurkar
<prathmesh.kallurkar@gmail.com> wrote:
> 1. Did you get the guest physical address for the load/store instructions?
> No, I am getting the guest virtual address for the load and store
> instructions.
>
>
>>
>> 2. The code you pasted seems translated code. The number of input code
>> could be smaller than this. So don't you think we should trap the
>> input code, instead of the translated code?
>
>
> I am trapping the guest code and NOT the translated code.  For this I am
> transferring the guest instruction bytes (using ldub_code) to a remote
> disassembler and then inspecting the instruction.
>
>>
>> > cmp ecx, [r12+0x4]
>> > mov r10b, [r13+0x0]
>> > mov byte [rax+0xf0000], 0x0
>> > mov byte [rax+rdx], 0x0
>
>
> The above instructions are instructions of a i386 guest system.

In the above code, can your disassembler get the value of the
register? For example what is in dcx or r12?

>>
>>
>> 3. Suppose that I have a tb block which has only one instruction to be
>> translated
>>             mov    0x4(%esp),%edx
>>     I tried to calculate the guest physical address of 0x4(%esp) in
>> the above in the function of disas_insns(...), is this possible? Or do
>> you have any other solutions?
>
>
> Sorry but seems I have not considered this case. See, I am just trapping the
> calls to tcg_gen_qemu_ld/st and then checking my coverage by inspecting the
> decoded instructions given by my disassembler. I flag an error when I
> receive an instruction which was supposed to contain a load/store
> instruction but I could not trace one. I will definitely see what I get for
> mov    0x4(%esp),%edx
>
I tried to trace the guest virtual address of the memory access in
this load instruction. However, the value of 0x4(%esp) seems to be
resolved at the translated code, instead of the disassemble step. Can
your diassembler resolve the value of 0x4(%esp)?

>
> --
> Regards,
> Prathmesh Kallurkar