Dynamic Software Updating

1. Dynamic Software Updating Michael Hicks Jonathan T. Moore Scott Nettles Presented by: Ruchi Gupta Ritu Varma Rohan Puri

2. Motivation & Solution • Motivation • Need of applications that run continuously without interruption • Need for fixing bugs and upgrading the functioning system • Must be achievable at low cost, easy to use, correct, and low overhead • Solution • Dynamic Software Updating (DSU) • Type-safe dynamic updating of native code in an extremely flexible manner • Implement dynamic patches • Use of semi-automated tools

3. Properties of Dynamic Software Updating System • Flexibility • permits changes at function granularity • types of data and functions can be updated • Correctness • ensured by proof-carrying code • Ease of use • patch generation semi-automated • Low Overhead • adding updating infrastructure has minimal overhead on application

4. What is Dynamic Patch? (1)

5. What is Dynamic Patch? (2) • State Transformer Function • used to convert existing state to a form usable by new code • applied when types are unaffected • Stub function • applied when types definition changes • interface between the old callers of function and new definitions • What if patch changes type of global variable? • then all the code that references that data must be simultaneously changed

6. Types of Updates • Code and Data Updates • reference to existing function calls and data be redirected to Stubs and new data definitions • Updating Type Definition • to preserve type-safety, • there is need to upgrade type definitions as understood by type checker used in dynamic linker.

7. Mechanism for Code and Data Updates • Rewriting • at update time the running code is rewritten to refer directly to appropriate parts of patch • normal compilation, no runtime cost (except at update time) • Indirection • applying the patch updates the indirection table to point to the new function definition. • simple to implements • small performance penalty

8. Mechanism for Code and Data Updates - Indirection

9. Mechanism for Updating Type Definition • Replacement • applying a patch replaces existing type definition with new one • care must be taken to convert existing instances also, whether in heap, stack • Renaming • rename occurrence of old names with new • instances of old type remains

10. Building Updateable Systems(1) • HOW ARE PATCHES GENERATED • Patch construction method • Compare old version with new version of code. • Automatically generate the patch file • Fill in the parts of the state transformer and stub functions , Adv? • Automatic Patch Generation • Identify changes to functions and data • Files parsed and type checked • Type definition comparison (new names for new types) • Value declaration comparison • Generate stub functions and state transformers • State translator code ( Global variables -changed and unchanged) • Default stubs for functions that have changed type • Generator inserts statement that raises an exception • Automatically generate call to new version of function • Type conversion function (example –struct)

11. Building Updateable Systems(2) • HOW CAN PATCHES BE CORRECTLY APPLIED • Correct timing of update is important • E.g. new version of num will not reflect the call of f • Undecidable task, has a very limited automated support • If automatic then certain restrictions apply • Timing enforced at compile time( software construction) rather than at run time • Adv:Implementation Complexity of update timing enforcement avoided • Disadv:System must be constructed appropriately else a costly affair

12. Implementation (1) • Framework (TYPED ASSEMBLY LANGUAGE AND SOURCE LANGUAGE-POPCORN) • How to implement Dynamic update by reference indirection • Add support to the existing dynamic linker to support dynamic updating • Linker consists of trusted(C and OCaml)) and untrusted part (Popcorn) • Linking and symbol management functionality in the untrusted part • Loading and verification occurs in the trusted part • At compile time all files have their external references indirected through a local Global offset table (GOT) • At link time the entries in the GOTs are tracked by the dynamic linker in Global dynamic symbol table. • For dynamic updating each GOT entry filled with the corresponding entry in the symbol table • File updated –old entry in the Symbol table -> new entry • Function changed type-old entry removed from table, points to stub, new entry points to new function

13. Implementation (2) int afunc() { return GOT.bfunc.1(); }GOT = { bfunc = }; int bfunc() { return 1; } Old entry Dynamic Symbol Table int bfunc(int a) { return 1+a; } int Stub::bfunc() { return bfunc(0); }

14. Implementation (3) • In addition- Rebinding, Customized Linking order and Exporting static variable. • GOT only stores references to externally defined variables local references are direct. • Disadv: Indirection penalty • Updates occur on files rather than procedure or individual data.Why?Adv? • Two levels of indirection used. Why?

15. Implementation (4) • HOW TO DEFINE AND COMPILE PATCHES • Patch description file • Implementation filename • Interface code filename • Shared type definitions • Type definitions to rename • Interface code file • Variable references w.r.t version- New::, Old:: Stub:: • Compilation of patches • Convert into a popcorn file • All type definitions common to the implementation file and sharing list are made externs in the implementation file • The rest (non externs) are prefixed with New:: • The interface and the implementation file concatenated together • Mappings from renaming list -> file’s type names

16. FLASHED Web Server • Event Loop for FLASH while(1) { select( args ….); process_requests(); accept_new_connections(); } • Two changes to FLASH to make it updateable • Maintenance command interface • Application connects to server and sends files. Select () processes, exits eventprocessing loop (to reflect any changes in the loop code). State saved. • Error Handling • Original Flash calls exit(). FLASHED raises exception , prints diagnostics, resets state, closes connections and restarts. Uninterrupted service.

17. Initial Version Version 2: pathname translation caching Version 3: file caching Version 4: directory listing and CGI Incremental Development of FLASHED FLASHED Web Server • Evolutionary Development. • Non-trivial changes between each version. • Changes in http connection structure • Patch files generated between each version • Automatic generation / manual glue code where required.

18. FLASHED Web Server • Performance overhead in updateable FLASED is 2%-6%. • Updated FLASHED should have the worst performance out of the three models, but results show otherwise. Why? • Other performance parameters • Double indirection penalty=28% • Single indirection penalty =19% • Overhead due to verifying and linking patch files

19. FLASHED Web Server Flexibility • Dynamic Linking • Developer anticipates the change • Makes provisions. New code can only be added in existing interfaces. • DYMOS • Changes on per function and per module basis. Changes to infinite loops. • Adds flexibility (like FLASHED) for old code to be active during updates. • Transition at well defined points like procedure calls / object creation.

20. FLASHED Web Server Flexibility • FLASHED • Compromise between the two approaches. Dynamic patches. • Know issues to be resolved • Unchecked updates Changes to trusted code base, like verifier (had this error during implementation). • Function pointers Indirection issues. Dereference the pointers late. Store actual address not pointer. • Namespace security Users executing code. Apply policy bases on loading environment. • Updating ADTs ADTs only visible to the local file. Difficult to update. Apply environment bases rights.

21. FLASHED Web Server • Correctness • Old and new code running in separate threads with the old phasing out the new. • Stopping the old code, updating it with new and running it with the old state • FLASHED approach. System is constructed such that update points are defined. Work needs to be done in determining the location of these safety points. • Ease of use • FLASHED scores over current frame works. Automatic generation of patch files with developers plugging in code where required. • Overhead • As discussed in the performance section the two levels of indirection entails very limited overhead.

22. Dynamic Software updating • Relevance to Embedded software • Organic development • Safety critical systems.