Performance & Storage

Our replay system takes a few space-overhead and reasonable computation-overhead.

Space-overhead of log are very small because of selective recording. Our replay system does not record all the executed instruction and all the I/O. We only take non-deterministic events into account for efficient recording. The log size average 350KB per minute; on the other hand, the recorded data increases 5.3 bytes per thousand of instructions.

Figure 7.3 Increase of log size per minute with random number of threads printing

The computation-overhead depends on the complexity of guest OS. We randomly execute linux command on small linux guest system, and execution time will cost about double times than native VM. Additionally, we also replay user behavior on Windows XP guest system, but the performance is not as good as small linux. The reason of computation slow down is that our replay system executes many condition branch and instructions. To count computed instructions, every instruction on guest system need to append an addition to instruction counter. However, the overhead of replaying is more than recording, because the recorded non-deterministic events must decide whether replays them or not each instruction.

Otherwise, the number of non-deterministic events will affect the replaying performance. The more data is recorded, the slower replaying is.

26

Table 7.1 Computation-overhead of replaying

Figure 7.4 Execution time of thread printing (exp1)

27

8. Future Work

Our system is extendable for replay of DMA and malware analysis. Even replay of DMA is a difficult problem; because of DMA is asynchronous IO operation. When guest system launches a DMA transmission, the virtual CPU will wait for virtual DMA interrupts for ensuring job finished. The arriving time of virtual DMA interrupts depend on host system IO operation. Unfortunately, we cannot predict the time consumption of host system that it is hard to replay the virtual DMA interrupts correctly. But it still has a solution for replaying.

We can halt the VM for waiting the host system data access finish. By doing this, guest system can access the data with correctly timing and keeps system states in a good shape.

Additionally, we plan to integrate a security analyzer in our system for security analysis tool such as dynamically taint analysis or intrusion detection system. It would be helpful for any kind of expensive compute consumption analysis.

28

9. Conclusion

Replaying execution sequence and recording the state transition of a system are very useful for software testing, malware analysis and post-attack recovery. Unfortunately, current approaches cannot provide complete replaying functionalities therefore they cannot be applied widely. Whole-system replay can recover the complete situation of previous execution time.

Non-intrusive recording can prevent the result from being interfered. Replaying correctly can guarantee that the sequence of executions is identical with that of the previous execution.

We implement a system based on QEMU for transparent and deterministic whole-system replay. Moreover, we can save the space of logs by only caring about the impacts of non-deterministic. The sequence of system replay must be deterministic if every factor of states transition is predictable. Our system is extendable by integrating other security analysis tool, thus enables its wide application in the future.

29

10. Reference

[1] P. Montesinos, L. Ceze, and J. Torrellas, “DeLorean: Recording and Deterministically Replaying Shared-Memory Multiprocessor Execution Ef?ciently,” in Proceedings of the 35th International Symposium on Computer Architecture, 2008.

[2] P. Montesinos, M. Hicks, S. T. King et al., “Capo: a software-hardware interface for practical deterministic multiprocessor replay,” in Proceeding of the 14th international conference on Architectural support for programming languages and operating systems, Washington, DC, USA, 2009.

[3] S. T. King, G. W. Dunlap, and P. M. Chen, “Debugging operating systems with time-traveling virtual machines,” in Proceedings of the annual conference on USENIX Annual Technical Conference, Anaheim, CA, 2005.

[4] J. Chow, T. Garfinkel, and P. M. Chen, “Decoupling dynamic program analysis from execution in virtual environments,” in USENIX 2008 Annual Technical Conference on Annual Technical Conference, Boston, Massachusetts, 2008.

[5] D. A. S. d. Oliveira, J. R. Crandall, G. Wassermann et al., “ExecRecorder: VM-based full-system replay for attack analysis and system recovery,” in Proceedings of the 1st workshop on Architectural and system support for improving software dependability, San Jose, California, 2006.

[6] G. W. Dunlap, D. G. Lucchetti, M. A. Fetterman et al., “Execution replay of multiprocessor virtual machines,” in Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, Seattle, WA, USA, 2008.

[7] G. W. Dunlap, S. T. King, S. Cinar et al., “ReVirt: enabling intrusion analysis through virtual-machine logging and replay,” SIGOPS Oper. Syst. Rev., vol. 36, no. SI, pp.

211--224, 2002.

[8] H. Liu, H. Jin, X. Liao et al., “XenLR: Xen-based Logging for Deterministic Replay,”

in Proceedings of the 2008 Japan-China Joint Workshop on Frontier of Computer Science and Technology, 2008.

[9] F. Qin, J. Tucek, Y. Zhou et al., “Rx: Treating bugs as allergies---a safe method to survive software failures,” ACM Trans. Comput. Syst., vol. 25, no. 3, pp. 7, 2007.

[10] J. Tucek, S. Lu, C. Huang et al., “Triage: diagnosing production run failures at the user's site,” in Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, Stevenson, Washington, USA, 2007.

[11] K. Nance, M. Bishop, and B. Hay, “Virtual Machine Introspection: Observation or Interference?,” IEEE Security and Privacy, vol. 6, no. 5, pp. 32--37, 2008.

[12] S. Yasushi, “Jockey: a user-space library for record-replay debugging,” in Proceedings

30

of the sixth international symposium on Automated analysis-driven debugging, Monterey, California, USA, 2005.

[13] S. M. Srinivasan, S. Kandula, C. R. Andrews et al., “Flashback: a lightweight extension for rollback and deterministic replay for software debugging,” in Proceedings of the annual conference on USENIX Annual Technical Conference, Boston, MA, 2004.

[14] S. Narayanasamy, G. Pokam, and B. Calder, “BugNet: Continuously Recording Program Execution for Deterministic Replay Debugging,” in Proceedings of the 32nd annual international symposium on Computer Architecture, 2005.

[15] M. Xu, R. Bodik, and M. D. Hill, “A "flight data recorder" for enabling full-system multiprocessor deterministic replay,” in Proceedings of the 30th annual international symposium on Computer architecture, San Diego, California, 2003.