On 6/17/25 3:24 AM, Alex Bennée wrote:
Rowan Hart <rowanbh...@gmail.com> writes:
From: novafacing <rowanbh...@gmail.com>
This patch adds functions to the plugins API to allow plugins to read
and write memory via hardware addresses. The functions use the current
address space of the current CPU in order to avoid exposing address
space information to users. A later patch may want to add a function to
permit a specified address space, for example to facilitate
architecture-specific plugins that want to operate on them, for example
reading ARM secure memory.
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Signed-off-by: Rowan Hart <rowanbh...@gmail.com>
<snip>
+/**
+ * qemu_plugin_write_memory_hwaddr() - write to memory using a hardware address
+ *
+ * @addr: A physical address to write to
+ * @data: A byte array containing the data to write
+ *
+ * The contents of @data will be written to memory starting at the hardware
+ * address @addr in the current address space for the current vCPU.
+ *
+ * This function does not guarantee consistency of writes, nor does it ensure
+ * that pending writes are flushed either before or after the write takes
place,
+ * so callers should take care when calling this function in plugin callbacks
to
+ * avoid depending on the existence of data written using this function which
+ * may be overwritten afterward. In addition, this function requires that the
+ * pages containing the address are not locked. Practically, this means that
you
+ * should not write instruction memory in a current translation block inside a
+ * callback registered with qemu_plugin_register_vcpu_tb_trans_cb.
+ *
+ * You can, for example, write instruction memory in a current translation
block
+ * in a callback registered with qemu_plugin_register_vcpu_tb_exec_cb, although
+ * be aware that the write will not be flushed until after the translation
block
+ * has finished executing. In general, this function should be used to write
+ * data memory or to patch code at a known address, not in a current
translation
+ * block.
My main concern about the long list of caveats for writing memory is the
user will almost certainly cause weird things to happen which will then
be hard to debug. I can see the patcher example however it would be
useful to know what other practical uses this interface provides.
I understand the concern that allowing modification of execution state
through plugins opens the path for possible bugs. However, it
significantly augment what is possible to do with them, especially for
security researchers, as Rowan listed in his answer.
For once, we have someone motivated to contribute upstream instead of
reinventing another downstream fork, so it should be encouraged.
As well, in case "weird things" happen and people file a bug report,
they will be free to share their plugin, so we can reproduce and solve
the problem. It should concern only users trying to modify state of
execution though, so definitely not the majority of plugins users.
Pierrick
