binaryanalysisplatform/qemu

Official QEMU mirror

qemu's Issues

Consider using TCG plugins

The support for tracing with TCG plugin has expanded greatly since this project was started:

• https://www.qemu.org/docs/master/devel/tcg-plugins.html
• https://gitlab.com/qemu-project/qemu/-/tree/master/contrib/plugins

See, for example, https://gitlab.com/qemu-project/qemu/-/blob/master/contrib/plugins/execlog.c

Switching to the plugins system would alleviate the need of hard work rebasing it for supporting newer QEMU versions.
It's one of the problems that PANDA struggles with:

• panda-re/panda#1383
• panda-re/panda#570 (comment)
• https://lore.kernel.org/qemu-devel/[email protected]/

Update to QEMU 8.2

This is necessary for the Tricore support: rizinorg/rz-tracetest#10

See:

• https://wiki.qemu.org/ChangeLog/8.0#Tricore
• https://wiki.qemu.org/ChangeLog/8.1#Tricore
• https://wiki.qemu.org/ChangeLog/8.2#Tricore

https://lore.kernel.org/qemu-devel/CAFEAcA_=Zp9YBcJDsCZ-UoMUyjBoG8XMkgfjS3_iGX9hWzM0=[e-mail]/

cc @imbillow

Archs to bump to QEMU 8.1:

• ARM/AArch64 - @thestr4ng3r
• x86 - @DMaroo
• PPC - @Rot127

Update the QEMU base

Currently it's based on 2.0 version, there were a lot of changes since, especially regarding new instructions, performance, and better APIs.

I think it would be awesome to update it to the latest stable version, e.g. 6.2.0: https://wiki.qemu.org/ChangeLog/6.2

Add CI to check PRs and commits

At least basic building and maybe QEMU style check script (to keep compatibility with the mainstream).

Add option to only save unique frames

Depending on the binary, traces can become very big (>10GB).

Especially for binaries which have many loops with not too much different input and output data (e.g. hash algorithms) we could reduce the trace size by only adding unique frames.

This could reduce testing time for them and save space.

Simply hashing the frames content for comparison should be enough?

Segfaults in PPC64 tracewrap

Running the following command (cross compiled rizin for PPC64 big endian) segfaults qemu.

qemu-ppc64 build_cross_ppc64be/binrz/rz-test/rz-test test/db/rzil/ppc32

Valgrind log has a ton of invalid reads of size 8

==14790== Thread 3:
==14790== Invalid read of size 8
==14790==    at 0x26DDC4: qemu_trace_endframe (tracewrap.c:348)
==14790==    by 0x26D874: qemu_trace_newframe (tracewrap.c:253)
==14790==    by 0x258544: helper_trace_newframe (trace_helper.c:40)
==14790==    by 0x59AF119: ???
==14790==  Address 0xf8b21b8 is 56 bytes inside a block of size 80 free'd
==14790==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==14790==    by 0x26DE7C: qemu_trace_endframe (tracewrap.c:359)
==14790==    by 0x258573: helper_trace_endframe (trace_helper.c:45)
==14790==    by 0x59AF944: ???
==14790==    by 0x1102: ???
==14790==    by 0x5800657F: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==14790==    by 0xF8B032F: ???
==14790==    by 0xF8B133F: ???
==14790==    by 0x1102: ???
==14790==    by 0x7800000000: ???
==14790==    by 0x1101: ???
==14790==    by 0x77537F: ???
==14790==  Block was alloc'd at
==14790==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==14790==    by 0x48DDE98: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==14790==    by 0x26D8B2: qemu_trace_newframe (tracewrap.c:260)
==14790==    by 0x258544: helper_trace_newframe (trace_helper.c:40)
==14790==    by 0x59AF8C0: ???
==14790==    by 0x1102: ???
==14790==    by 0x5800657F: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==14790==    by 0xF8B032F: ???
==14790==    by 0xF8B133F: ???
==14790==    by 0x1102: ???
==14790==    by 0x7800000000: ???
==14790==    by 0x1101: ???
==14790== 

...

@ivg Could you please assign me to this issue so I don't forget to fix it?

Branching strategy

I (tried) to rebase the tracewrap-6.20 branch onto the newest stable QEMU and it is not fun.
There are a bunch of conflicts.

I suggest we agree on a branch strategy. Because if one person does the rebase and has to fix 2+ architectures every time, we definitely end up with false tracing (because we have no proper tests).

How about we have a main branch which only implements the core of tracewrap.

We can call it tracewrap-X.Y, which is the current newest stable branch of QEMU + one or few more commits with the core tracewrap code.
This one is easily updated if QEMU has a new release. It could (should?) be even automated with the CI.

From this every arch branches. If some needs to trace a specific arch they select the archs branch.
If it needs a rebase onto the newest tracewrap-X.Y, fine. But since the user will use it anyway, it gets directly tested.

cc @thestr4ng3r @DMaroo Since ARM and x86/i386 had many many conflicts.