1 / 19

Presentation of Failure-Oblivious Computing vs. Rx

Presentation of Failure-Oblivious Computing vs. Rx. OS Seminar, winter 2005 by Lauge Wullf and Jacob Munk-Stander January 4 th , 2006. Agenda. Introduction Failure-Oblivious Computing Rx: Treating Bugs As Allergies. Introduction. Problem Reliability (deterministic and non-deterministic)

gage
Download Presentation

Presentation of Failure-Oblivious Computing vs. Rx

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Presentation of Failure-Oblivious Computing vs. Rx OS Seminar, winter 2005 by Lauge Wullf and Jacob Munk-Stander January 4th, 2006

  2. Agenda • Introduction • Failure-Oblivious Computing • Rx: Treating Bugs As Allergies

  3. Introduction • Problem • Reliability (deterministic and non-deterministic) • Cause • Software defects account for up to 40% of system failures • Memory- and concurrency related bugs cause more than 60% of system vulnerabilities • Effect • Expensive

  4. Introduction • Solutions • Safe languages, e.g. ML, Java or C# • Rebooting/restarting • Whole program restart, micro rebooting, etc. • Check pointing and recovery • Check point, roll back on failure, re-execute • Application specific • Multi-process model, exception handling, etc. • Non-conventional approaches • E.g. failure-oblivious computing

  5. Failure-Oblivious Computing • An instance of acceptability-oriented computing: • A flawed system must ensure that it respects basic acceptability properties, e.g.: • System must never accelerate the vehicle beyond a specific velocity • System should continue to execute even if it has a memory error • Makes invalid memory accesses oblivious • Invalid reads return manufactured values • Invalid writes are discarded • Thus, no termination of processes or exceptions

  6. Failure-Oblivious Computing, cont. • Behavior • Standard Compilation • memory corruption, potential crash • Safe Compilation • process terminates without potentially contaminating global data • Failure-Oblivious Compilation • process continues execution, speculative, unsafe execution path

  7. Failure-Oblivious Computing, cont. • Example, Pine 4.44 • Index uses From field of messages • Quotes certain characters • Bug when quoting certain values • Maximum length is miscalculated, thus a too small buffer is allocated for quoted value • Standard and Safe: Pine crashes on start • FOC: Pine operates “normally”

  8. Failure-Oblivious Computing, cont. • Example, bug-server (fictional) • FOC uses malloc/free to monitor memory access • Memory deallocation takes up much time,bug-server2.0 uses memory pools: • pool *new_pool()creates a new pool for memory allocation • void *pool_alloc(pool *p, size_t size)allocates size bytes from the pool p • void free_pool(pool *p)frees all memory allocated to pool p • Pools internally use malloc to create new or extend pools, free to free pools • A security exploit is released, affects only 2.0, why?

  9. Failure-Oblivious Computing, cont. • Extension to gcc • Implemented using checking code and continuation code • Checking code evaluates whether a memory access is valid or not • Continuation code executes when an invalid memory access occurs • Discards erroneous writes • Manufactures a sequence of results for erroneous reads, [0, 1, 2, 0, 1, 3, 0, 1, 4, …]

  10. Failure-Oblivious Computing, cont. • Checking code • based on Jones and Kelley’s scheme • enhanced by Ruwase and Lam • Jones and Kelley’s scheme • A table maps locations to data units • A data unit is e.g. a struct, array, variable • The table tracks intended data units and is used to distinguish in-bounds from out-of-bounds pointers

  11. Failure-Oblivious Computing, cont. • Base Case – always in-bounds • Base pointer is the address of an array, struct or variable. • Intended data unit is the corresponding data unit of base pointer • Pointer Arithmetic • Starting pointer + offset • In-bound if and only if starting pointer and derived pointer point to the same data unit • Intended data unit is the same for both • Does not work with “reverse” pointer arithmetic? • Pointer Variables • In-bound if-and-only if it was assigned to in-bound pointer • Intended data unit is the same as the pointer to which it was assigned

  12. Failure-Oblivious Computing, cont. • Valid out-of-bounds pointer • Points to the next byte after intended data unit • Obtained by padding each data item with an extra byte • Illegal out-of-bounds-pointer have value ILLEGAL (-2) • Used to support valid out-of-bounds pointers in terminating loops when using pointer arithmetic

  13. Failure-Oblivious Computing, cont. • Dereferencing pointer, checks table: • in-bounds pointer returns referent value • out-of-bounds pointer causes program to halt with error • Does not support pointer arithmetic used to obtain a pointer to a location past the end of intended data unit, which is then used to calculate an in-bound

  14. Failure-Oblivious Computing, cont. • Ruwase and Lam’s enhancement • Out-of-bounds pointers are set to point to out-of-bounds (OOB) object • OOB object: • Start address of intended data unit • Offset from this address • Can track out-of-bounds pointers to their intended data unit

  15. Failure-Oblivious Computing, cont. • Pros • Global state is not corrupted • Local data accessed in loops • Individual iteration failures can be handled • Servers without state • No propagation of errors beyond a single request • Interactive programs • Programs do not crash • Can show meaningful results • Tolerable slow-down

  16. Failure-Oblivious Computing, cont. • Cons: • “safe compiler for C” • What if this introduces bugs? • Only C? • Programs must be recompiled • Always in use, not only when needed • Manufactured reads can lead to wrong execution path, i.e. not for correctness-critical applications • Only tested in the case of Midnight Commander

  17. Failure-Oblivious Computing, cont. • Cons, cont. • “The key question is how (or even if) the incorrect or unexpected result may propagate through the remaining computation to affect the overall results of the program” • How to determine this is not answered • Vaguely mentions that FOC is less appropriate for such cases • Global change, thus might only be suited for isolated functionality, i.e. local

  18. Failure-Oblivious Computing, cont. • Cons, cont. • Patch-management • Rather have a fixed system than one which seems to run fine, but might not • “Lucky” cases: • Pine – different method used elsewhere • Sendmail – length-check catches error • Midnight Commander – dangling link minimizes error • Mutt – server returns “does not exist”

  19. Failure-Oblivious Computing, cont. • Performance • Programs that would crash earlier continue execution • Slowdown from 1.03 to 8.1 times the original performance

More Related