Hacker News new | ask | show | jobs
by xvilka 9 days ago
The problem is that it's not sustainable - QEMU improved so much since the moment of fork and updating the QEMU code in Unicorn is always done manually. It is especially important for architectures that evolve quickly - ARM64, RISC-V, x86. Meanwhile, QEMU now has the notion of TCG plugins[1] that can read/write registers and memory, which is enough for most cases. You can see many examples of the plugins in contrib/plugins[2] directory of the mainline QEMU - a good starting point.

[1] https://www.qemu.org/docs/master/devel/tcg-plugins.html

[2] https://gitlab.com/qemu-project/qemu/-/tree/master/contrib/p...
2 comments
novafacing 8 days ago
This is actually the whole reason I wrote the patches that allow you to read and write memory and registers. I work on fuzzing, and fuzzing tools are a fragmented ecosystem of QEMU forks and patches that are outdated the moment they are published. Even PANDA from MIT LL which has great support struggled to keep their patches rebased and compatible with QEMU's actually-pretty-fast releases. Upstream or bust, it's really not that hard, it just takes a little persistence (and with LLMs learning git email is easy)!
link
Retr0id 8 days ago
This looks useful for a lot of instrumentation use cases, but less so for building custom emulators, if I'm understanding it correctly.
link
novafacing 8 days ago
Plugins would definitely be the wrong tool for the job for actual new emulator development, but if you needed to do something easy like add an NVRAM for a router rehost you could do that with plugins e.g. by skipping an instruction and using a callback to implement the desired behavior (as long as it is something a plugin is allowed to do -- you can't access device memory yet).
link
xvilka 8 days ago
For this, I believe, working with the mainline is more promising path, at least to reduce the amount of changes needed[1].

[1] https://gitlab.com/qemu-project/qemu/-/work_items/1896

link