Message ID | 20210618091101.2802534-1-erdnaxe@crans.org (mailing list archive) |
---|---|
Headers | show |
Series | execlog TCG plugin to log instructions | expand |
Supersedes: <20210614090116.816833-1-erdnaxe@crans.org> On 6/18/21 11:10 AM, Alexandre Iooss wrote: > execlog is a plugin that logs executed instructions with some useful > metadata including memory access. > > The output of the plugin is designed to be usable with other tools. For > example it could be used with a side-channel leakage model to create > side-channel traces from QEMU for security evaluation. > > Changes since v1: > - The output is now easier to parse. > - Use QEMU logging API rather than FILE* to write output. > - Don't reject memory information in user mode. > - Merge memory information with instruction execution. Now one line > means one instruction. > - Add documentation. > > Alexandre Iooss (2): > contrib/plugins: add execlog to log instruction execution and memory > access > docs/devel: tvg-plugins: add execlog plugin description > > MAINTAINERS | 1 + > contrib/plugins/Makefile | 1 + > contrib/plugins/execlog.c | 123 +++++++++++++++++++++++++++++++++++++ > docs/devel/tcg-plugins.rst | 22 +++++++ > 4 files changed, 147 insertions(+) > create mode 100644 contrib/plugins/execlog.c >
Alexandre Iooss <erdnaxe@crans.org> writes: > execlog is a plugin that logs executed instructions with some useful > metadata including memory access. > > The output of the plugin is designed to be usable with other tools. For > example it could be used with a side-channel leakage model to create > side-channel traces from QEMU for security evaluation. > > Changes since v1: > - The output is now easier to parse. > - Use QEMU logging API rather than FILE* to write output. > - Don't reject memory information in user mode. > - Merge memory information with instruction execution. Now one line > means one instruction. > - Add documentation. Where you planning on posting v3? I'm just seeing if we can get this merged before code freeze in a weeks time.
On 7/1/21 8:49 PM, Alex Bennée wrote: > > Alexandre Iooss <erdnaxe@crans.org> writes: > >> execlog is a plugin that logs executed instructions with some useful >> metadata including memory access. >> >> The output of the plugin is designed to be usable with other tools. For >> example it could be used with a side-channel leakage model to create >> side-channel traces from QEMU for security evaluation. >> >> Changes since v1: >> - The output is now easier to parse. >> - Use QEMU logging API rather than FILE* to write output. >> - Don't reject memory information in user mode. >> - Merge memory information with instruction execution. Now one line >> means one instruction. >> - Add documentation. > > Where you planning on posting v3? I'm just seeing if we can get this > merged before code freeze in a weeks time. > I had a deadline next week but I managed to move it later, so I can try to make the important changes tomorrow and send v3. I think I will contribute the support for triggering the beginning and end of tracing in another patch as I believe that's something we don't want to rush. Thanks, -- Alexandre
Alexandre IOOSS <erdnaxe@crans.org> writes: > [[PGP Signed Part:Undecided]] > > > On 7/1/21 8:49 PM, Alex Bennée wrote: >> Alexandre Iooss <erdnaxe@crans.org> writes: >> >>> execlog is a plugin that logs executed instructions with some useful >>> metadata including memory access. >>> >>> The output of the plugin is designed to be usable with other tools. For >>> example it could be used with a side-channel leakage model to create >>> side-channel traces from QEMU for security evaluation. >>> >>> Changes since v1: >>> - The output is now easier to parse. >>> - Use QEMU logging API rather than FILE* to write output. >>> - Don't reject memory information in user mode. >>> - Merge memory information with instruction execution. Now one line >>> means one instruction. >>> - Add documentation. >> Where you planning on posting v3? I'm just seeing if we can get this >> merged before code freeze in a weeks time. >> > > I had a deadline next week but I managed to move it later, so I can > try to make the important changes tomorrow and send v3. Cool. > I think I will contribute the support for triggering the beginning and > end of tracing in another patch as I believe that's something we don't > want to rush. That's fine ;-)