Self Rcovery in Server Programs在服务器程序自恢复.pptVIP

Self Recoveryin Server Programs The University of California, Riverside Server Availability Long-running server programs: availability threatened by software failures Memory errors a significant problem Buffer overflows, format string errors, etc. National Vulnerability Database, 2008: 30% software failures caused by memory errors Memory bug defect ? triggered by user request ? memory corruption ? crash, or software attack due to malicious user input Checkpointing/Rollback Technique One commonly used technique to recover from a failure [Gray ‘86, Plank ’98, Qin ’05, Randell ’78, Tallam ’08] Main principle Periodically checkpoint state On failure, rollback to most recent safe state Replay benign user requests from safe state to failure point Limitations Checkpointing can have high overhead Rollback can affect throughput and response time Inherent tradeoff Small checkpoint interval ? rollback improved, but time/space overhead Large checkpoint interval ? overhead improved, but throughput and response time degrades Memory Corruption Propagation Is expensive checkpointing/rollback scheme necessary? Perhaps, if memory corruption undergoes significant propagation Perhaps not, if memory corruption is relatively isolated Memory corruption Memory location contains an unexpected value (e.g., overflow) Memory corruption propagation The spreading of memory corruption as computation progresses New values become corrupt due to existing corrupt values Corrupt values become uncorrupted when they are overwritten with an uncorrupt value (e.g., reusing a variable) How Corruption Propagates Does the number of corrupted locations steadily increase? Dominated by “uncorrupt ? corrupt” transitions Very quickly, memory may be filled with corrupt locations and computation can’t proceed May justify the need for checkpointing/rollback Or, does the number of corrupted locations stabilize or vanish? Significant “corrupt ? uncorrupt” transitions This “self cleansing” can be leverage