Enhancing Server Availability and Security Through Failure-Oblivious Computing

By Martin C. Rinard, Cristian Cadar, Daniel Dumitran, Daniel M. Roy, Tudor Leu, W. Beebee. USENIX Symposium on Operating Systems Design and Implementation, 2004

368 citations recorded by the source corpus.

View Paper: https://www.semanticscholar.org/paper/df2be604d11ad6c8514f4d8f394ff86de988cc97

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

Citations in the corpus

Staged program repair with condition synthesis (2015, background): “Failure-Oblivious Computing: Failure-oblivious computing [33] checks for out of bounds reads and writes.”
Cores that don't count (2021, background): “[19] described “failure-oblivious” techniques for systems to keep computing across memory errors; it is not clear if these would work for CEEs.”
Automatically finding patches using genetic programming (2009, background): “[25] present a notion of failure-oblivious computing, in which compiler-inserted bounds checks discard invalid memory accesses, allowing servers to avoid security attacks.”
Debugging in the (very) large: ten years of implementation and experience (2009, background): “Failure-oblivious computing [29] and Rx [28] hide failures by either altering the execution environment or fabricating data.”
Automatically patching errors in deployed software (2009, background): “Both failureoblivious computing [35, 33, 36] and transactional function termination [42, 41] enable a range of servers to survive errors and attacks.”
Automatic patch generation by learning correct code (2016, background): “Failure-Oblivious Computing, RCV, and RIFL: Failure-oblivious computing [29] checks for out of bounds reads and writes.”
Rx: treating bugs as allergies---a safe method to survive software failures (2005, methodology): “The most straightforward method in this category is to checkpoint, rollback upon failures, and then re-execute either on the same machine [23, 42] or on a different machine designated as the backup server (either active or passive) [26, 5, 10, 11, 57, 2, 60].”
Testing static analysis tools using exploitable buffer overflows from open source code (2004, methodology): “Dynamic prevention approaches such as Stackguard, CCured, and CRED [9, 11, 24, 23 ] detect some buer overflows at run time, only to turn them into DoS attacks because a program halts in order to prevent a buer overflow.”
SGXBOUNDS: Memory Safety for Shielded Execution (2017, background): “tions, (2) increased availability instead of the usual fail-stop semantics by tolerating out-of-bounds accesses based on failureoblivious computing [64, 65], and lastly, (3) generic APIs for objects’ metadata management to support new use-cases.”
Baggy Bounds Checking: An Efficient and Backwards-Compatible Defense against Out-of-Bounds Errors (2009, background): “On the other hand, being faster makes it more suitable for production runs, and tolerating faults in production runs may be desired [29].”
Vigilante: end-to-end containment of internet worms (2005, methodology): “[34] propose using a C compiler that inserts runtime checks for illegal memory accesses.”
Post-compiler software optimization for reducing energy (2014, background): “Taken together, the growing popularity of acceptability-oriented computing [48–50] and the difﬁculty of manually optimizing for energy [17, 35, 47], suggest that automatically reducing energy and manually focusing on semantics is a proﬁtable tradeoff compared to the traditional converse.”
DieHard: probabilistic memory safety for unsafe languages (2006, background): “9 Error GNU libc [25] BDW GC [9] CCured [27] Rx [30] Failure-oblivious [32] DieHard”