* Handle the cpu context save in a more pythonic way, so the context can be serialized and reuse in an other process using the same emulator architecture and modes
* Fix type error ; mistakes a size_t uint64_t ; breaks in 32bit...
* Fix the UAF situation when deleting a hook while being in a hook callback. Added an attribute 'to_delete' to hooks, and a list hooks_to_del to delay the free of the hooks
* Minor fixes ; forgot return type of clear_deleted_hooks ; do not declare variable in for predicate
This change removes the check for stop requests from the hook loop
macro.
Requests to stop emulation (uc_emu_stop) should only affect whether
the emulation stops. This isn't the case at present for the invocation
of hooks. If emulation is requested to be stopped (which is indicated
by `uc->stop_request`), the hooks will skip all execution. This means
that when the emulation stop is requested, some expected operations
may not occur before the emulation exits - leaving the system in an
inconsistent or broken state.
This is particularly obvious in the case where a CPU interrupt is
required, and a hook has been registered for such cases. The expected
operation is that the hook be called, and no CPU exception be raised
(because the hook has handled it). However, because of the short-cut
in the case where the `uc_emu_stop` function has been called out of
band (eg on another thread), this hook would not be called. In such
cases the execution would terminate with an error that an 'unhandled
CPU exception' occurred, and the hook would never have been called.
This probably affects other parts of the system, such as hooks which
handle remapping of memory on demand (UC_HOOK_MEM_READ_UNMAPPED and
friends) where the remap would not happen and instead an error about
the unmapped memory would be raised.
In all cases, it makes sense that execution continue normally until
the outer loop which controls the execution determines that the
emulation should stop. This will mean that for any given sequence of
events all the emulation operations are completed deterministically
regardless of when the stop request was received.
Writing / reading to model specific registers should be as easy as
calling a function, it's a bit stupid to write shell code and run them
just to write/read to a MSR, and even worse, you need more than just a
shellcode to read...
So, add a special register ID called UC_X86_REG_MSR, which should be
passed to uc_reg_write()/uc_reg_read() as the register ID, and then a
data structure which is uc_x86_msr (12 bytes), as the value (always), where:
Byte Value Size
0 MSR ID 4
4 MSR val 8
* reg_read and reg_write now work with registers W0 through W30 in Aarch64 emulaton
* Added a regress test for the ARM64 reg_read and reg_write on 32-bit registers (W0-W30)
Added a new macro in uc_priv.h (WRITE_DWORD_TO_QWORD), in order to write to the lower 32 bits of a 64 bit value without overwriting the whole value when using reg_write
* Fixed WRITE_DWORD macro
reg_write would zero out the high order bits when writing to 32 bit registers
e.g. uc.reg_write(UC_X86_REG_EAX, 0) would also set register RAX to zero
Support for Cortex-M ARM CPU already exists in Qemu. This patch just
exposes a "cortex-m3" CPU.
"uc_open(UC_ARCH_ARM, UC_MODE_THUMB | UC_MODE_MCLASS, &uc);"
Instantiates a CPU with this feature on.
Signed-off-by: Lucian Cojocar <lucian@cojocar.com>
ARM and probably the rest of the arches have significant memory leaks as
they have no release interface.
Additionally, DrMemory does not have 64-bit support and thus I can't
test the 64-bit version under Windows. Under Linux valgrind supports
both 32-bit and 64-bit but there are different macros and code for Linux
and Windows.
