> I am personally in favor to adding such features in upstream QEMU, but we > should discuss it with the maintainers, because it would allow to change the > state of execution, which is something qemu plugins actively didn't try to > do. It's a real paradigm shift for plugins. > > By writing to memory/registers, we can start replacing instructions and > control flow, and there is a whole set of consequences to that. >
Totally agree! As much as I really want this functionality for plugins, I think alignment on it is quite important. I can see very cool use cases for being able to replace instructions and control flow to allow hooking functions, hotpatching, and so forth. I don't really know the edge cases here so your expertise will be helpful. In the worst case I can imagine: what would happen if a callback overwrote the next insn? I'm not sure what behavior I would expect if that insn has already been translated as part of the same tb. That said, the plugin is aware of which insns have already been translated, so maybe it is not unreasonable to just document this as a "don't do that". Let me know what you think. > The hypercall functionality would be useful for plugins as a whole. And I > think it definitely deserves to be worked on, if maintainers are open to that > as well. Sure, I'd be happy to work on this some more. At least on the fuzzing side of things, the way hypercalls are done across hypervisors (QEMU, Bochs, etc) is pretty consistent so I think we could provide a useful common set of functionality. The reason I did the bare minimum here is I'm not familiar with every architecture, and a good NOP needs to be chosen for each one along with a reasonable way to pass some arguments -- I don't know if I'm the right person to make that call. Glad to hear you're for this idea! -Rowan
