qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] contrib/plugins: add execlog to log instruction execution an


From: Alexandre IOOSS
Subject: Re: [PATCH] contrib/plugins: add execlog to log instruction execution and memory access
Date: Wed, 16 Jun 2021 17:15:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2

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: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]