From: Alexandre IOOSS <erdnaxe@crans.org>
To: "Alex Bennée" <alex.bennee@linaro.org>,
"Mahmoud Mandour" <ma.mandourr@gmail.com>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] contrib/plugins: add execlog to log instruction execution and memory access
Date: Wed, 16 Jun 2021 17:15:25 +0200 [thread overview]
Message-ID: <fe85f44b-a7a6-1b59-daa6-c5b6b81a2112@crans.org> (raw)
In-Reply-To: <adf3164e-84dc-b96b-c671-0805175d0394@crans.org>
[-- Attachment #1.1: Type: text/plain, Size: 2688 bytes --]
On 6/15/21 6:47 PM, Alexandre IOOSS wrote:
> On 6/15/21 10:22 AM, Alex Bennée wrote:
>> Mahmoud Mandour <ma.mandourr@gmail.com> writes:
>>> On 14/06/2021 11:01, Alexandre Iooss wrote:
>>>> +}
>>>> +
>>>> +/**
>>>> + * Log instruction execution
>>>> + */
>>>> +static void vcpu_insn_exec(unsigned int cpu_index, void *udata)
>>>> +{
>>>> + char *insn_disas = (char *)udata;
>>>> +
>>>> + /* Add data to execution log */
>>>> + fprintf(output, "insn: %s\n", insn_disas);
>>
>> insn, 0x%08lx, disas
>>
>> Currently however on a multi-threaded execution you will potentially
>> loose any synchronisation between the insn_exec and any memory operation
>> associated with it. If you really just care about what's tickling
>> hardware you could just drop the insn_exec callback and pass the
>> instruction information via udata to the vcpu_mem callback. You could
>> then dump everything in one line:
>>
>> 0xPC, ld [x1], x2, 0xADDR, load|store
>>
>> you wouldn't dump other instructions leading up to that though.
>
> You are correct, this is indeed an issue and it's currently making my
> life really hard when I try to apply a side-channel model on the memory
> interactions.
> I prefer to log all instructions, so I need to use vcpu_mem_cb when it's
> a memory instruction, or vcpu_insn_exec_cb if it's not.
If I always set vcpu_mem_cb and vcpu_insn_exec_cb, then an user can do a
bit of postprocessing of the data to merge lines that correspond to
memory interactions. Example of output (Cortex-M0 in Thumb mode):
```
# vaddr, opcode, disassembly, [load/store, memory addr, device]
0xa14, 0xf87f42b4, "cmp r4, r6"
0xa16, 0xd206, "bhs #0xa26"
0xa18, 0xfff94803, "ldr r0, [pc, #0xc]"
0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM
0xa1a, 0xf989f000, "bl #0xd30"
0xd30, 0xfff9b510, "push {r4, lr}"
0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM
0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee4, RAM
0xd32, 0xf9893014, "adds r0, #0x14"
0xd34, 0xf9c8f000, "bl #0x10c8"
0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]"
0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x200000e4, RAM
```
If we don't want to call `vcpu_insn_exec_cb` when `vcpu_mem_cb` is
triggered, then I would have either to:
1. Implement load/store instructions matchers, similar to what is done
in `howvec.c` plugin.
2. Implement instructions mnemonic matchers (using the output of
qemu_plugin_insn_disas).
3. Use Capstone and disassemble a second time each instructions.
What is your opinion on these solutions? Maybe for a first version we
can keep it simple?
Thanks,
-- Alexandre
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2021-06-16 15:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 9:01 [PATCH] contrib/plugins: add execlog to log instruction execution and memory access Alexandre Iooss
2021-06-14 17:04 ` Mahmoud Mandour
2021-06-15 8:22 ` Alex Bennée
2021-06-15 16:47 ` Alexandre IOOSS
2021-06-16 15:15 ` Alexandre IOOSS [this message]
2021-06-17 9:55 ` Alex Bennée
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=fe85f44b-a7a6-1b59-daa6-c5b6b81a2112@crans.org \
--to=erdnaxe@crans.org \
--cc=alex.bennee@linaro.org \
--cc=ma.mandourr@gmail.com \
--cc=qemu-devel@nongnu.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).