Hi Daniel, My apologies for the late reply, I've been out of office the past two weeks.
Yeah, this sounds like it is potentially going a step too far in enabling fully out of tree extension of core QEMU functionality. If something conceptually is in scope of the core QEMU codebase, then IMHO, our plugin system should aim to avoid enabling external implementations as far as is practical. That was easy when plugins were limited to observability, but the more we enable in terms of state modification the wider pandora's box is opened. Where to draw the line is a hard problem.
As I'm new to the QEMU mailing list (not to tinkering with QEMU / implementing things in or on top of QEMU, though), I'm not fully familiar with the requirement of preventing out of tree extensions (or at least certain functionality in such plugins). I personally (of course with a somewhat biased view :)) see features that allow modifying internal state (such as syscall behavior) as beneficial or even required for certain dynamic binary analysis use cases. Currently, the situation in academic research is that researchers (i.e., typically PhD students) for dynamic analysis use cases fork QEMU and implement their use case directly in the core logic. Such patches can of course never be upstreamed, as they're very use-case-specific and typically don't generalize to the full QEMU functionality (or might even break / deteriorate other functionality that's not relevant to this specific use case). As soon as the corresponding project is considered "done" / "finished", the code basically just rots and never gets rebased onto newer versions of QEMU anymore, basically freezing it in time with all current bugs and without potential future improvements to QEMU's core. That's why I personally actually really love QEMU's plugin interface: it allows me to introspect the system state without adding custom hooks everywhere in the code that might not be portable to newer QEMU versions! Consequently, my code is reusable either by myself later on or other researchers with any version of QEMU that supports at least the specified plugin API version. However, I often wish to modify QEMU's state as well, such as in the provided example with modifying syscall return values or skipping over a syscall altogether. Do I understand correctly that handling syscalls is considered in scope of the core QEMU codebase and therefore shouldn't be possible to do via a plugin? If I understand correctly, as it stands, there's no way to modify syscall behavior on an emulator-level with QEMU instead of at the kernel-level via seccomp, eBPF, kernel modules, ... Best regards, Florian
