1. Dynamic Software Updates: The State Mapping Problem Rida A. Bazzi Kristis Makris Peyman Nayeri Jun Shen ARIZONA STATE UNIVERSITY

2. The Software Update Problem Replace an old version of an application with a new version of the application oldnew

3. old new

4. old new State mapping 1.How to affect the mapping: mechanism? 2.How to determine if a safe mapping is possible?

5. A general mechanism for state mapping Supports immediate updates of multi- threaded applications Supports update for applications with blocking system calls An application written in C is made updateable using code instrumentation

6. State Reconstruction: to update active functions Transforming blocking calls to non-blocking calls. Forcing all threads to block before an update. – Stack reconstruction for every thread – Resumption up to the update point for all – Resumption for all

8. TAMING THE STATE MAPPING PROBLEM Assumption – Some degree of backward compatibility should be expected Approach – Ignore some differences: log functions – Reduce the state that needs to be mapped: wait for light-weight functions to exit – Take advantage of backward compatibility assumption: semantic checking with unification

9. LIGHT WEIGHT FUNCTIONS Functions that are guaranteed to exit in a bounded amount of time No need to map state! We do not solve the halting problem

10. STRICT DEFINITION A function as lightweight if: Does not contain loops Does not call itself recursively Does not call synchronization functions (locks, semaphores, …) Does not call a non-lightweight function Does not read input

11. STRICT DETECTION Initially, we have – Lists of lightweight and heavyweight library functions – List of unknown library functions (we have not gone through all of them yet) Any function that does not satisfy the strict definition is heavyweight Any function that calls a heavyweight function is heavyweight For the remaining functions: – Repeat until there are no changes: If a function only calls lightweight functions, add it to the list of lightweight functions

12. LIGHT WEIGHT FUNCTIONS: INITIAL NUMBERS ApplicationTotalLightUnknownHeavy Apache5563142150 IceCast692346131215 OpenSSH13344558790 PostgresSQL58531236459819 vsFTP6062313750 Moral: even simple analysis can go a long way

13. OTHER INTERESTING STATISTICS ApplicationTotalRecursionUnknown Libary Loops Apache556619388 IceCast692818175 OpenSSH1334629281 PostgresSQ L 5853141215371 vsFTP606212415

14. LOG FUNCTIONS LOG-related functions: functions that write log files Disregard difference that are due to log function differences!!

15. LOG FUNCTIONS: DETECTION 1.String arguments 2.Write only (fprintf, printf (not persistent), write, …) 3.Heavily used: no. of callers * no. of call sites 4.recursively : called by log-functions exclusively. This is somewhat counter-intuitive and we should modify it to work bottom up. 5.Name has log (not logarithms!) We can detect the “top” log function, but we miss some of them 10% of changes are due to automatically detected log functions

16. ENHANCEMENTS: BACKWARD COMPATIBLE UPDATES if (newOption) x = y*z; else x = y+z; w = x/2; x = w-z; /* update point */ (b) new version x = y+z; w = x/2; x = w-z; /* update point */ (a) Old version

17. MAPPING FOR ENHANCEMENTS How to map state so that the execution after the update is equivalent to the execution before the update? For the example above: set NewOption to false In general, we need to compare the semantics of the two applications Use of code slicing to compare the two executions

18. CODE SLICING WITH UNIFICATION

19. BUG FIXES... x = y+z; w = x/2; x = w-z; /* update point */ (a) old version... if (x > y) x = y+z; w = x/2; x = w-z; /* update point */ (b) new version The state mapping is Impossible: cannot tell if x > y Trivial : disregard and hope for the best: this is the update problem not the state repair problem!) Not quite so!

20. BUG FIXES WITH CHECKPOINTING Checkpoint everywhere Check x1 > y1 at the update point Not practical!... x = y+z; w = x/2; x = w-z; /* update point */ (a) old version... if (x1 > y2) x2 = y+z; w1 = x2/2; x3 = w2-z1; /* update point */ (b) new version

21. BUG FIXES WITH CHECKPOINTING Checkpoint at – function entry – Interactions with environment Re-execute at time of update: should take relatively little time for non-compute bound applications – Assumes no change to interfaces with environment – Re-execution simulates interactions with environment... x = y+z; w = x/2; x = w-z; /* update point */ (a) old version... if (x > y) x = y+z; w = x/2; x = w-z; /* update point */ (b) new version

22. QUESTIONS?