| Message ID | 20210618091101.2802534-3-erdnaxe@crans.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | execlog TCG plugin to log instructions | expand |
Alexandre Iooss <erdnaxe@crans.org> writes: > This adds description of the execlog TCG plugin with an example. > > Signed-off-by: Alexandre Iooss <erdnaxe@crans.org> > --- > docs/devel/tcg-plugins.rst | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst > index 18c6581d85..02818a3327 100644 > --- a/docs/devel/tcg-plugins.rst > +++ b/docs/devel/tcg-plugins.rst > @@ -319,3 +319,25 @@ the user to see what hardware is accessed how often. It has a number of options: > off:0000001c, 1, 2 > off:00000020, 1, 2 > ... > + > +- contrib/plugins/execlog.c > + > +The execlog tool traces executed instructions with memory access. It can be used > +for debugging and security analysis purposes. We should probably mention that this will generate a lot of output. Running the admittedly memory heavy softmmu memory test: ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \ -plugin contrib/plugins/libexeclog.so \ -cpu max -serial mon:stdio -M virt \ -display none -semihosting-config chardev=serial0 \ -kernel ./tests/tcg/aarch64-softmmu/memory generates a 8.6Gb text file. I suspect once this is merged you might want to look at options to target the instrumentation at areas of specific interest or abbreviate information. > +The plugin takes no argument:: > + > + qemu-system-arm $(QEMU_ARGS) \ > + -plugin ./contrib/plugins/libexeclog.so -d plugin > + > +which will output an execution trace following this structure:: > + > + # vCPU, vAddr, opcode, disassembly[, load/store, memory addr, device]... > + 0, 0xa12, 0xf8012400, "movs r4, #0" > + 0, 0xa14, 0xf87f42b4, "cmp r4, r6" > + 0, 0xa16, 0xd206, "bhs #0xa26" > + 0, 0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM > + 0, 0xa1a, 0xf989f000, "bl #0xd30" > + 0, 0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM, store, 0x20003ee4, RAM > + 0, 0xd32, 0xf9893014, "adds r0, #0x14" > + 0, 0xd34, 0xf9c8f000, "bl #0x10c8" > + 0, 0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x200000e4, RAM
Alexandre Iooss <erdnaxe@crans.org> writes: <snip> Sorry also missed s/tvg/tcg/ in the subject line.
On 6/22/21 10:48 AM, Alex Bennée wrote: > Alexandre Iooss<erdnaxe@crans.org> writes: >> [...] >> + >> +The execlog tool traces executed instructions with memory access. It can be used >> +for debugging and security analysis purposes. > We should probably mention that this will generate a lot of output. > Running the admittedly memory heavy softmmu memory test: > > ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \ > -plugin contrib/plugins/libexeclog.so \ > -cpu max -serial mon:stdio -M virt \ > -display none -semihosting-config chardev=serial0 \ > -kernel ./tests/tcg/aarch64-softmmu/memory > > generates a 8.6Gb text file. I suspect once this is merged you might > want to look at options to target the instrumentation at areas of > specific interest or abbreviate information. Yes! In my downstream version I am triggering the beginning and the end of trace acquisition by matching two virtual addresses of GPIO device access. This works in my case because I'm also using the same GPIO for triggering an oscilloscope, but maybe we would like to upstream something more generic. I'm still thinking about this (maybe for a later patch) but I believe it would be nice to have the following: - If no argument is given to the plugin, log everything. - Allow the user to specify either a memory address, an instruction virtual address or an opcode that would start the acquisition. - Same to stop the acquisition. This would look like this to start/stop acquisition using GPIO PA8 on STM32VLDISCOVERY: ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \ -kernel ./firmware.elf -d plugin \ -plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424 I would like to hear other users opinion on this, because I fear I might implement something too specific. Thanks, -- Alexandre
Alexandre IOOSS <erdnaxe@crans.org> writes: > [[PGP Signed Part:Undecided]] > On 6/22/21 10:48 AM, Alex Bennée wrote: >> Alexandre Iooss<erdnaxe@crans.org> writes: >>> [...] >>> + >>> +The execlog tool traces executed instructions with memory access. It can be used >>> +for debugging and security analysis purposes. >> We should probably mention that this will generate a lot of output. >> Running the admittedly memory heavy softmmu memory test: >> ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \ >> -plugin contrib/plugins/libexeclog.so \ >> -cpu max -serial mon:stdio -M virt \ >> -display none -semihosting-config chardev=serial0 \ >> -kernel ./tests/tcg/aarch64-softmmu/memory >> generates a 8.6Gb text file. I suspect once this is merged you might >> want to look at options to target the instrumentation at areas of >> specific interest or abbreviate information. > > Yes! In my downstream version I am triggering the beginning and the > end of trace acquisition by matching two virtual addresses of GPIO > device access. This works in my case because I'm also using the same > GPIO for triggering an oscilloscope, but maybe we would like to > upstream something more generic. > > I'm still thinking about this (maybe for a later patch) but I believe > it would be nice to have the following: > - If no argument is given to the plugin, log everything. > - Allow the user to specify either a memory address, an instruction > virtual address or an opcode that would start the acquisition. > - Same to stop the acquisition. Sounds reasonable to me. > This would look like this to start/stop acquisition using GPIO PA8 on > STM32VLDISCOVERY: > > ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \ > -kernel ./firmware.elf -d plugin \ > -plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424 I quite like the formats you can use for -dfilter, for example: 0x1000+0x100,0x2100-0x100,0x3000..0x3100 it might even be worth exposing qemu_set_dfilter_ranges as a helper function to plugins to avoid copy and paste. So what would your above command trigger? A write to 1073809424 would start the trace and the next write to the same address would stop it? > I would like to hear other users opinion on this, because I fear I > might implement something too specific. > > Thanks, > -- Alexandre > > [[End of PGP Signed Part]]
On 6/22/21 12:37 PM, Alex Bennée wrote: > > Alexandre IOOSS <erdnaxe@crans.org> writes: > >> [[PGP Signed Part:Undecided]] >> On 6/22/21 10:48 AM, Alex Bennée wrote: >>> Alexandre Iooss<erdnaxe@crans.org> writes: >>>> [...] >>>> + >>>> +The execlog tool traces executed instructions with memory access. It can be used >>>> +for debugging and security analysis purposes. >>> We should probably mention that this will generate a lot of output. >>> Running the admittedly memory heavy softmmu memory test: >>> ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \ >>> -plugin contrib/plugins/libexeclog.so \ >>> -cpu max -serial mon:stdio -M virt \ >>> -display none -semihosting-config chardev=serial0 \ >>> -kernel ./tests/tcg/aarch64-softmmu/memory >>> generates a 8.6Gb text file. I suspect once this is merged you might >>> want to look at options to target the instrumentation at areas of >>> specific interest or abbreviate information. >> >> Yes! In my downstream version I am triggering the beginning and the >> end of trace acquisition by matching two virtual addresses of GPIO >> device access. This works in my case because I'm also using the same >> GPIO for triggering an oscilloscope, but maybe we would like to >> upstream something more generic. >> >> I'm still thinking about this (maybe for a later patch) but I believe >> it would be nice to have the following: >> - If no argument is given to the plugin, log everything. >> - Allow the user to specify either a memory address, an instruction >> virtual address or an opcode that would start the acquisition. >> - Same to stop the acquisition. > > Sounds reasonable to me. > >> This would look like this to start/stop acquisition using GPIO PA8 on >> STM32VLDISCOVERY: >> >> ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \ >> -kernel ./firmware.elf -d plugin \ >> -plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424 > > I quite like the formats you can use for -dfilter, for example: > > 0x1000+0x100,0x2100-0x100,0x3000..0x3100 > > it might even be worth exposing qemu_set_dfilter_ranges as a helper > function to plugins to avoid copy and paste. We could expose "-dfilter", but maybe it is better to reserve it to filter the output of the plugin rather than triggering the tracing? I could implement a format similar to dfilter to configure triggering. This would enable someone to start logging on any access to a memory range. > > So what would your above command trigger? A write to 1073809424 would > start the trace and the next write to the same address would stop it? > Yes exactly. In this case the first access set the GPIO high, and the second access set it low. I don't believe the plugin can access the value stored in memory (i.e. differentiating between setting a GPIO output high or low). I don't find this problematic in my case, but maybe it could be for someone else. From the discussion I see the following possible patches: 1. Add an argument to trigger the beginning with one address (memory or instruction). 2. Add an argument to trigger the end with one address (memory or instruction). 3. Add the support for ranges (in "dfilter" style). 4. (maybe) Add the support to trigger on an opcode. 5. Add support for "-dfilter" to filter the logging output. Thanks, -- Alexandre
Alexandre IOOSS <erdnaxe@crans.org> writes: > [[PGP Signed Part:Undecided]] > On 6/22/21 12:37 PM, Alex Bennée wrote: >> Alexandre IOOSS <erdnaxe@crans.org> writes: >> >>> [[PGP Signed Part:Undecided]] >>> On 6/22/21 10:48 AM, Alex Bennée wrote: >>>> Alexandre Iooss<erdnaxe@crans.org> writes: >>>>> [...] >>>>> + >>>>> +The execlog tool traces executed instructions with memory access. It can be used >>>>> +for debugging and security analysis purposes. >>>> We should probably mention that this will generate a lot of output. >>>> Running the admittedly memory heavy softmmu memory test: >>>> ./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \ >>>> -plugin contrib/plugins/libexeclog.so \ >>>> -cpu max -serial mon:stdio -M virt \ >>>> -display none -semihosting-config chardev=serial0 \ >>>> -kernel ./tests/tcg/aarch64-softmmu/memory >>>> generates a 8.6Gb text file. I suspect once this is merged you might >>>> want to look at options to target the instrumentation at areas of >>>> specific interest or abbreviate information. >>> >>> Yes! In my downstream version I am triggering the beginning and the >>> end of trace acquisition by matching two virtual addresses of GPIO >>> device access. This works in my case because I'm also using the same >>> GPIO for triggering an oscilloscope, but maybe we would like to >>> upstream something more generic. >>> >>> I'm still thinking about this (maybe for a later patch) but I believe >>> it would be nice to have the following: >>> - If no argument is given to the plugin, log everything. >>> - Allow the user to specify either a memory address, an instruction >>> virtual address or an opcode that would start the acquisition. >>> - Same to stop the acquisition. >> Sounds reasonable to me. >> >>> This would look like this to start/stop acquisition using GPIO PA8 on >>> STM32VLDISCOVERY: >>> >>> ./arm-softmmu/qemu-system-arm -M stm32vldiscovery \ >>> -kernel ./firmware.elf -d plugin \ >>> -plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424 >> I quite like the formats you can use for -dfilter, for example: >> 0x1000+0x100,0x2100-0x100,0x3000..0x3100 >> it might even be worth exposing qemu_set_dfilter_ranges as a helper >> function to plugins to avoid copy and paste. > > We could expose "-dfilter", but maybe it is better to reserve it to > filter the output of the plugin rather than triggering the tracing? I meant the parsing code for dfilter style expressions, the dfilter itself ;-) > I could implement a format similar to dfilter to configure triggering. > This would enable someone to start logging on any access to a memory > range. > >> So what would your above command trigger? A write to 1073809424 >> would >> start the trace and the next write to the same address would stop it? >> > > Yes exactly. In this case the first access set the GPIO high, and the > second access set it low. > > I don't believe the plugin can access the value stored in memory (i.e. > differentiating between setting a GPIO output high or low). I don't > find this problematic in my case, but maybe it could be for someone > else. Not currently but in principle it wouldn't be too hard to do. It would just be extra data to copy into a TCG Arg. We would probably want to make it optional though. > > From the discussion I see the following possible patches: > 1. Add an argument to trigger the beginning with one address (memory > or instruction). > 2. Add an argument to trigger the end with one address (memory or > instruction). > 3. Add the support for ranges (in "dfilter" style). > 4. (maybe) Add the support to trigger on an opcode. > 5. Add support for "-dfilter" to filter the logging output. > > Thanks, > -- Alexandre > > [[End of PGP Signed Part]]
diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst index 18c6581d85..02818a3327 100644 --- a/docs/devel/tcg-plugins.rst +++ b/docs/devel/tcg-plugins.rst @@ -319,3 +319,25 @@ the user to see what hardware is accessed how often. It has a number of options: off:0000001c, 1, 2 off:00000020, 1, 2 ... + +- contrib/plugins/execlog.c + +The execlog tool traces executed instructions with memory access. It can be used +for debugging and security analysis purposes. +The plugin takes no argument:: + + qemu-system-arm $(QEMU_ARGS) \ + -plugin ./contrib/plugins/libexeclog.so -d plugin + +which will output an execution trace following this structure:: + + # vCPU, vAddr, opcode, disassembly[, load/store, memory addr, device]... + 0, 0xa12, 0xf8012400, "movs r4, #0" + 0, 0xa14, 0xf87f42b4, "cmp r4, r6" + 0, 0xa16, 0xd206, "bhs #0xa26" + 0, 0xa18, 0xfff94803, "ldr r0, [pc, #0xc]", load, 0x00010a28, RAM + 0, 0xa1a, 0xf989f000, "bl #0xd30" + 0, 0xd30, 0xfff9b510, "push {r4, lr}", store, 0x20003ee0, RAM, store, 0x20003ee4, RAM + 0, 0xd32, 0xf9893014, "adds r0, #0x14" + 0, 0xd34, 0xf9c8f000, "bl #0x10c8" + 0, 0x10c8, 0xfff96c43, "ldr r3, [r0, #0x44]", load, 0x200000e4, RAM
This adds description of the execlog TCG plugin with an example. Signed-off-by: Alexandre Iooss <erdnaxe@crans.org> --- docs/devel/tcg-plugins.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)