From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
To: Rowan Hart <rowanbhart@gmail.com>, qemu-devel@nongnu.org
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Alexandre Iooss" <erdnaxe@crans.org>,
"Mahmoud Mandour" <ma.mandourr@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [PATCH v2 0/3] Add additional plugin API functions to read and write memory and registers
Date: Fri, 6 Dec 2024 11:43:14 -0800 [thread overview]
Message-ID: <55c95bd1-a1bc-460c-b4fe-1f52f8af2c2e@linaro.org> (raw)
In-Reply-To: <20241206102605.961658-1-rowanbhart@gmail.com>
Hi Rowan,
thanks for this submission!
On 12/6/24 02:26, Rowan Hart wrote:
> This patch set follows a previous patch which added the
> qemu_plugin_read_memory_vaddr function and adds a set of similar
> functions to read and write registers, virtual memory, and
> physical memory.
>
> The use case I have in mind is for use of QEMU for program analysis and
> testing. For example, a fuzzer which uses QEMU for emulation might wish to
> inject test data into a program at runtime using qemu_plugin_write_memory_vaddr
> (and likewise if testing an operating system or bare metal application using
> qemu_plugin_write_memory_hwaddr). It may also wish to read the initial contents
> of memory using qemu_plugin_read_memory_vaddr/hwaddr.
>
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.
> Similarly, a testing framework may wish to fake register values, perhaps to
> simulate a device failure, perhaps by using qemu_plugin_write_register to set a
> register value to an error code.
>
> I think all this functionality works together to make QEMU
> plugins more powerful and versatile, hopefully removing barriers
> to using upstream QEMU for these tasks which have historically
> required maintaining a QEMU fork downstream (like QEMUAFL
> https://github.com/AFLplusplus/qemuafl), which is tedious, error
> prone, and results in users missing out on enhancements to QEMU.
>
> A test is provided, compile:
>
> gcc -o tests/tcg/x86_64/inject-target tests/tcg/x86_64/inject-target.c
>
> And run:
>
> ./build/qemu-x86_64 -d plugin --plugin build/tests/tcg/plugins/libinject.so tests/tcg/x86_64/inject-target
>
> Hopefully after a number of tries, the inject plugin will inject the right
> value into the target program, leading to a victory message. This plugin
> handles simple "hypercalls", only one of which is implemented and injects
> data into guest memory.
>
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.
> novafacing (3):
> Expose gdb_write_register function to consumers of gdbstub
> Add plugin API functions for register R/W, hwaddr R/W, vaddr W
> Add inject plugin and x86_64 target for the inject plugin
>
> gdbstub/gdbstub.c | 2 +-
> include/exec/gdbstub.h | 14 +++
> include/qemu/qemu-plugin.h | 116 +++++++++++++++--
> plugins/api.c | 66 +++++++++-
> tests/tcg/plugins/inject.c | 206 +++++++++++++++++++++++++++++++
> tests/tcg/plugins/meson.build | 2 +-
> tests/tcg/x86_64/Makefile.target | 1 +
> tests/tcg/x86_64/inject-target.c | 27 ++++
> 8 files changed, 418 insertions(+), 16 deletions(-)
> create mode 100644 tests/tcg/plugins/inject.c
> create mode 100644 tests/tcg/x86_64/inject-target.c
>
Regards,
Pierrick
next prev parent reply other threads:[~2024-12-06 19:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 10:26 [PATCH v2 0/3] Add additional plugin API functions to read and write memory and registers Rowan Hart
2024-12-06 10:26 ` [PATCH v2 1/3] Expose gdb_write_register function to consumers of gdbstub Rowan Hart
2025-01-09 12:03 ` Alex Bennée
2024-12-06 10:26 ` [PATCH v2 2/3] Add plugin API functions for register R/W, hwaddr R/W, vaddr W Rowan Hart
2025-01-09 12:22 ` Alex Bennée
2024-12-06 10:26 ` [PATCH v2 3/3] Add inject plugin and x86_64 target for the inject plugin Rowan Hart
2024-12-06 19:57 ` Pierrick Bouvier
2024-12-07 1:02 ` Rowan Hart
2024-12-09 18:38 ` Pierrick Bouvier
2024-12-06 19:43 ` Pierrick Bouvier [this message]
2024-12-07 0:57 ` [PATCH v2 0/3] Add additional plugin API functions to read and write memory and registers Rowan Hart
2024-12-09 18:45 ` Pierrick Bouvier
2024-12-10 11:38 ` Alex Bennée
2024-12-10 18:40 ` Pierrick Bouvier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55c95bd1-a1bc-460c-b4fe-1f52f8af2c2e@linaro.org \
--to=pierrick.bouvier@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=eduardo@habkost.net \
--cc=erdnaxe@crans.org \
--cc=ma.mandourr@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=rowanbhart@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).