Deterministic Replay of QEMU Emulation

1. panda

   1 9 2,591 7.8 C

   Platform for Architecture-Neutral Dynamic Analysis (by panda-re)

   

   Indeed, the tooling is the problem. And I wouldn't hold my breath to see this tooling being implemented, as the feature has been around for quite a bit.

   IMHO, PANDA [1] remains a better/more practical choice for whole-system record/replay analysis. It already offers quite a bit of tooling (including a python interface), as well as hooks to build your own. It does have its own shortcomings (speed and not being in-sync with the latest QEMU), but at least you're not limited to gdb-based debugging.

   [1] https://panda.re/

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. QEMU

   2 202 11,314 10.0 C

   Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website.

   

   It is very cool, but I think some version of this feature has been around for years? This commit is from 7 years ago, and it looks like the code originates back to 2010.

   https://github.com/qemu/qemu/blob/v2.9.0/docs/replay.txt

   That said, I was not aware of it until I saw this post, and I definitely want to play around with it.

4. jos

   3 2 23 6.8 Rust

   Experimental busy dad's operating system written from scratch

   

   Tried to apply it for debugging on my own OS, but couldn’t get it finally running after several days of trial and error…

   https://github.com/jbreu/jos

5. rr

   4 118 9,832 9.4 C++

   Record and Replay Framework

   

   I don't know, however a key element is:

   > Record/replay system is based on saving and replaying non-deterministic events

   > The following non-deterministic data from peripheral devices is saved into the log: mouse and keyboard input, network packets, audio controller input, serial port input, and hardware clocks (they are non-deterministic too, because their values are taken from the host machine). Inputs from simulated hardware, memory of VM, software interrupts, and execution of instructions are not saved into the log, because they are deterministic and can be replayed by simulating the behavior of virtual machine starting from initial state.

   So, it's probably not much, you can probably comfortably save minutes of qemu sessions.

   Also note the existence of the rr debugger [1], which allows you to reverse debug applications with a ~10% performance hit while recording. To achieve this, it records results of syscalls (only). It will serialize thread events, so have the effect of running applications like on a single core CPU.

   [1] https://rr-project.org/

6. madness

   5 13 238 6.7 Nix

   Madness enables you to easily run the same binary on NixOS and non-NixOS systems (by antithesishq)

   

7. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

Suggest a related project