diff options
Diffstat (limited to 'debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md')
| -rw-r--r-- | debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md b/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md index a2a45db..90ca799 100644 --- a/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md +++ b/debug/risc-v-gsp-rm-vm/docs/10-RELATED-WORK.md @@ -11,7 +11,7 @@ frida-agent requires a hosted OS process. The GSP image is bare-metal RV64 with its own libos; there is nothing to inject into, and even a hypothetical RISC-V port would need an OS layer the firmware does not have. -**Where the Frida *idea* lives in green-eye:** the scripting model. `Session` +**Where the Frida *idea* lives in risc-v-gsp-rm-debugger:** the scripting model. `Session` offers `hook`/`watch`/`memory`/`events` with Python callbacks, which is the part of Frida that matters for this workflow. The difference is transport: RSP to QEMU instead of an injected agent. @@ -24,23 +24,23 @@ guest today. ## 2. GDB / gdbstub QEMU's gdbstub is the transport both tools share. GDB itself is still useful -for *debugging green-eye* (stub behaviour, protocol traces), and `gdb +for *debugging risc-v-gsp-rm-debugger* (stub behaviour, protocol traces), and `gdb -multiarch` can inspect the same target interactively. It is not the instrumentation layer here because: * every operation becomes a subprocess/parse problem instead of an API call; * recording, symbol annotation, structure decoding and session diffing would have to be rebuilt around GDB/MI anyway; -* the project already uses GDB Python scripts for the CUDA corpus; green-eye +* the project already uses GDB Python scripts for the CUDA corpus; risc-v-gsp-rm-debugger is the equivalent for firmware, with a stronger data model. ## 3. QEMU TCG plugins The correct complement, not a competitor: plugins execute inside QEMU and can observe **every** instruction and memory access, which gdbstub breakpoints -cannot. green-eye's `qemu/greeneye_trace.c` emits a JSONL access trace for +cannot. risc-v-gsp-rm-debugger's `qemu/greeneye_trace.c` emits a JSONL access trace for exactly this; integrating it into the session format is R4 on the roadmap. -Rule of thumb: use green-eye hooks for semantics ("handler X ran with these +Rule of thumb: use risc-v-gsp-rm-debugger hooks for semantics ("handler X ran with these args") and TCG plugins for coverage/heatmaps ("every write to this window"). ## 4. Unicorn / emulator libraries @@ -55,17 +55,17 @@ reason the roadmap defers that work. `rr` does not support RISC-V guests and records at the host-process level. QEMU's own record/replay (`-icount`) can provide deterministic reruns later; -green-eye's session recording occupies a different niche (semantic events, +risc-v-gsp-rm-debugger's session recording occupies a different niche (semantic events, not full replay) and can coexist. ## 6. Comparison table -| Tool | Layer | RISC-V firmware | green-eye relationship | +| Tool | Layer | RISC-V firmware | risc-v-gsp-rm-debugger relationship | |---|---|---|---| | Frida | userland process injection | no | conceptual model only | -| GDB + gdbstub | execution control | yes (transport) | debugging green-eye; same stub | +| GDB + gdbstub | execution control | yes (transport) | debugging risc-v-gsp-rm-debugger; same stub | | QEMU TCG plugin | full instruction/memory trace | yes | complement (R4) | -| green-eye | semantic instrumentation + recording + analysis | yes | this tool | +| risc-v-gsp-rm-debugger | semantic instrumentation + recording + analysis | yes | this tool | | Unicorn/rv8/etc. | CPU emulation library | yes | R2 candidate | | Ghidra | static decompilation | yes | symbol/hit bridge (05) | |