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; } int bfunc(int a) { return 1+a; } int Stub::bfunc() { return bfunc(0); } Dynamic Symbol TableOld entry

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 event processing 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 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. Version 2: pathname translation caching Version 3: file caching Version 4: directory listing and CGI Initial Version Incremental Development of FLASHED

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.