Mapping memory from guest to host

163 views
Skip to first unread message

Craig Miles

unread,
Aug 5, 2013, 1:59:31 PM8/5/13
to s2e...@googlegroups.com
Hi,

How can I map memory from the guest S2E VM into the virtual address space of the host process (an S2E plugin), similar to what xc_map_foreign_pages() allows in Xen?  I see there are potentially a couple of different options:

exec.c::emu_get_ram_ptr() - There's a note in S2EExecutionState.cpp that says this shouldn't be used directly, because "mapping of IO memory can be modified"
exec.c::cpu_physical_memory_map() - You guys made some modifications to this function so it would work with S2E, but I don't see it actually being used anywhere in the S2E code.  Does it work?

I suspect cpu_physical_memory_map() is what I'm looking for.  Are there any dangers in its usage I should be aware of?

Thanks for any info,
Craig

Vitaly Chipounov

unread,
Aug 5, 2013, 4:58:41 PM8/5/13
to s2e...@googlegroups.com, Craig Miles
Hi,


On 05.08.2013 19:59, Craig Miles wrote:
How can I map memory from the guest S2E VM into the virtual address space of the host process (an S2E plugin), similar to what xc_map_foreign_pages() allows in Xen?  I see there are potentially a couple of different options:

It's hard. S2E splits guest pages into chunks of 128 bytes (configurable). Each chunk lives in a different klee::ObjectState.
Every memory access done by QEMU is wrapped in order to redirect it to the right chunk.
You could make the chunks 4K and then access them directly, but you'd still have to be careful.

In practice, it is a lot easier to write instrumentation code in the guest. You could leverage onInstrTranslateStart to hijack guest's execution and redirect it to some guest code (write an S2E plugin that pushes the next instruction's address on the guest's stack and set the program counter to your guest code. When your guest function returns, execution will continue transparently).




exec.c::emu_get_ram_ptr() - There's a note in S2EExecutionState.cpp that says this shouldn't be used directly, because "mapping of IO memory can be modified"
exec.c::cpu_physical_memory_map() - You guys made some modifications to this function so it would work with S2E, but I don't see it actually being used anywhere in the S2E code.  Does it work?

This is used by some guest device IIRC. Memory mapped in this way is temporary and is normally flushed on state switches.



I suspect cpu_physical_memory_map() is what I'm looking for.  Are there any dangers in its usage I should be aware of?

I guess you could try this out. It will use a bounce buffer to copy data back and forth between your local view and the actual ObjectStates.
You can't write symbolic data this way though and it only works at the guest physical level.

Can you describe what problem are you trying to solve? There might be alternative solutions.

Vitaly
Reply all
Reply to author
Forward
0 new messages