Dominik Czarnota <dominik.b.czarn...@gmail.com> writes:
> Hi,
>
> We need the `qqemu.Pid` packet only for the QEMU system part in order
> to figure out the page tables and to do it efficiently.
Page tables of QEMU itself or the page tables for the guest its managing?
> We do have a fallback to using `monitor info mem` but it is slow, (iirc)
> doesn't provide all the necessary information and
> (iirc) isn't implemented on all architectures.
That can be fixed. If it's useful information to clients of QEMU it
would be better to have a well defined API for accessing it.
This is a gdb monitor call and not an HMP one right?
> Also, is the QEMU own pid leak such a problem? There are worse issues than
> that available with current features though I
> believe they are not really security issues. I will detail this in a
> private email to you.
Sure - enabling gdbstub inherently gives the user quite privileged
access to QEMU's guests - including the ability to execute arbitrary
syscalls on behalf of the remote.
My main concern is adding support for a non-standard packet that is used
for a hacky workaround when a better solution might be possible.
>
> Best,
> Dominik 'Disconnect3d' Czarnota
>
> On Fri, 2 May 2025 at 15:18, Alex Bennée <alex.ben...@linaro.org> wrote:
>
> Dominik 'Disconnect3d' Czarnota <dominik.b.czarn...@gmail.com> writes:
>
> > This patch adds support for the `qqemu.Pid` packet to the qemu
> > gdbstub which can be used by clients to get the QEMU process PID.
> >
> > This is useful for plugins like Pwndbg [0] or gdb-pt-dump in order to
> > inspect the QEMU process memory through the /proc/self/{maps,mem}
> > interfaces. Without this feature, they have to rely on doing an
> > unreliable pgrep/ps output processing.
>
> That seems a little thin a reason for QEMU to expose its own PID. For
> user-mode you can already get that detail through anything using
> gdb_append_thread_id().
>
> For system-mode leaking QEMU's own pid seems like an information leak at
> best. There are modes like semihosting which give a remote even more
> power but you need to at least opt in to that.
>
> >
> > This patch has been developed by Patryk, who I included in the
> > Co-authored-by and who asked me to send the patch.
> >
> > [0] https://github.com/pwndbg/pwndbg
> > [1] https://github.com/martinradev/gdb-pt-dump
> >
> > Co-authored-by: Patryk 'patryk4815' Sondej <patryk.son...@gmail.com>
> > Signed-off-by: Dominik 'Disconnect3d' Czarnota
> <dominik.b.czarn...@gmail.com>
> > ---
> > gdbstub/gdbstub.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> > index 282e13e163..a077c2c5ed 100644
> > --- a/gdbstub/gdbstub.c
> > +++ b/gdbstub/gdbstub.c
> > @@ -1746,6 +1746,12 @@ static void handle_query_qemu_supported(GArray
> *params, void *user_ctx)
> > gdb_put_strbuf();
> > }
> >
> > +static void handle_query_qemu_pid(GArray *params, void *user_ctx)
> > +{
> > + g_string_printf(gdbserver_state.str_buf, "F%x", getpid());
> > + gdb_put_strbuf();
> > +}
> > +
> > static const GdbCmdParseEntry gdb_gen_query_set_common_table[] = {
> > /* Order is important if has same prefix */
> > {
> > @@ -1902,6 +1908,10 @@ static const GdbCmdParseEntry gdb_gen_query_table[]
> = {
> > .handler = handle_query_qemu_supported,
> > .cmd = "qemu.Supported",
> > },
> > + {
> > + .handler = handle_query_qemu_pid,
> > + .cmd = "qemu.Pid",
> > + },
> > #ifndef CONFIG_USER_ONLY
> > {
> > .handler = gdb_handle_query_qemu_phy_mem_mode,
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
