Secure Compiler Seminar 516 Survey Dynamic Software Updating

Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating Toshihiro YOSHINO (D 1, Yonezawa Lab. ) <tossy-2@yl. is. s. u-tokyo. ac. jp>

References n M. Hicks, S. Nettles. Dynamic Software Updating. In ACM Transactions on Programming Languages and Systems (TOPLAS), 27(6), pp. 1049 -1096, 2005.

Background n Need for nonstop computer systems ¨ Especially n for mission critical applications Financial transaction processors, telephone switches, … ¨ Such systems must be upgraded without interruption n For example, redundant hardware as hot standbys ¨ e. g. Visa uses 21 mainframes

Background n Redundant hardware requires high cost ¨ Extra hardware is required ¨ Application specific support is also needed ⇒ Dynamic software updating ¨ Update running system without shutting down

Design Goals n Flexibility ¨ Any n part of a program should be upgraded Robustness ¨ Minimize the risk of errors and crashes due to an update n Ease of use ¨ Make n system simple Low overhead ¨ Making a program updateable should impact its performance as little as possible

Existing Approaches are not Enough n Flexibility: Many systems limit capabilities ¨ Possible to add new code, n Hot-slide in ML [Appel 1994] but not to replace ¨ Even for systems that allow replace, what/when/how update happens is limited Dynamic ML [Gilmore et al. 1997] can update named types only, and update is possible when the target code is inactive n Dynamic C++ [Hjalmtysson, Gray 1998] cannot change types of functions and values n

Existing Approaches are not Enough n Robustness: Many systems have few safeguards to ensure update correctness ¨ Type safety is broken due to using unsafe languages ¨ Use error-prone complex hand-generated patch n Ease of Use: Many systems rely on uncommon programming language ¨ DYMOS [Lee 1983], n Argus [Bloom 1983], etc. Low Overhead: Some systems impose high runtime overhead ¨ Due to implementation complexities, interpretation n Type-safe dynamic Java classes [Malabarba et al. 2000]

Approach n Combine TAL and dynamic linking ¨ New module is loaded using dynamic linking States are transformed by user-supplied code n Replacement is just to overwrite existing symbol table n ¨ TAL is used to assure a patch is safe A well-typed TAL program is memory-safe, controlflow safe and stack-safe n A patch cannot crash the system or perform incorrect actions n

Dynamic Patches n A dynamic patch is a tuple where f’ is new definition of a module ¨ S is a state transformer ¨ n Translates module states (values, types) When a patch is loaded, state transformer is called to transform states 2. Then the system is updated, and calls to the updated function are handled by new code 1.

System Implementation n Use dynamic linking ¨ Dynamic link a patch, transform state locally and switch to use the new code ¨ Type-safe dynamic linker for TAL [Hicks et al. 2000] cf. Marshal/unmarshal of states ¨ Can be used also for migration ¨ But at the same time has many drawbacks n n n Update always effects the entire program Many things including heap, stack, etc. must be transformed correctly Kernel state cannot be easily moved

System Implementation How to Update Code? n Two major ways ¨ Code n relinking The rest of the program is relinked to call the new function after a patch is loaded ¨ Reference n indirection Store all function pointers into a global table and modify the table on update

System Implementation > How to Update Code? Code Relinking Approach module A int afunc() { … return bfunc(); } module B int bfunc() { return 1; } Linking occurs again, updating all existing External reference is reference to bfunc() resolved on startup module B’ (linking) int bfunc() { return 2; }

System Implementation > How to Update Code? Reference Indirection Approach module A Indirection table int afunc() { … return bfunc(); } Overwriting the table makes functions calls module B redirected to new code int bfunc() { return 1; } External references are indirected with this table module B’ int bfunc() { return 2; }

System Implementation How to Update Code? n They chose code relinking ¨ Does not impose extra overhead n Reference indirection indirects all function calls, so it affects performance ¨ Implementation can be simple n Possible to reuse existing dynamic linker to perform relink ¨ In both ways, existing function pointer must be translated by a transformer

System Implementation How to Update Type Definitions? n Again, two major approaches ¨ Replacement n State transformer transforms all data in old types on update ¨ Renaming Data in old types and new types are intermixed n State transformer or stub functions translates old data when needed n

System Implementation > How to Update Type Definitions? Replacement Approach typedef struct { int a; } t; tt typedef struct { int a; int b; } t; a a= =1 1 b=0 typecheck the program with: tt a a= =2 2 b=0 t -> struct { int a; int b; }

System Implementation > How to Update Type Definitions? Renaming Approach typedef struct { int a; } t; t a=1 typedef struct { int a; int b; } t_new; t_new a = 1 b=0 typecheck the program with: t a=2 t -> struct { int a; } t_new -> struct { int a; int b; }

System Implementation How to Update Type Definitions? n They chose renaming here ¨ Replacement is complex to implement ¨ Without technological support, replacement may lead to inconsistency in type checking On update, the system must find all the instances of old types n It must be assured in some means that the system transformed all the instances n

System Implementation How to Trigger Update? n Here again, two major approaches ¨ Interrupt Active update (from the viewpoint of updater) n Application is not aware of update n ¨ Invoke n Application programmers describe explicitly when update occurs in their applications

System Implementation How to Trigger Update? n They chose invoke approach ¨ Interrupt n Programmer must specify the conditions under which a module is updateable ¨ n is difficult to realize In DYMOS [Lee 1983], a patch can be given along with the conditions for update to happen It is typically difficult to specify such conditions ¨ There are systems which automatically find updateable point in a program, but they are too conservative

Generate a Patch n Differentiate source codes ¨ Find modified files ¨ Compare the signatures of types, codes, … ¨ Write stub functions and state transformer ¨ Most process is tedious work and can be automated n Finding what is modified and how it is modified

Generate a Patch Automatic Patch Generator Inputs Outputs

Automatic Patch Generator Comparing Definitions n Comparison is done syntactically ¨ If a definition depends on changed types or values, then it is considered to be changed n If a type is changed, a new type is created ¨ Rename with MD 5 checksum for prettyprinted definitions n The same definition produces the same name

Automatic Patch Generator Auxiliary Files n Typename map ¨ Used to keep track of type definitions that have changed ¨ The file holds the associations of old and new types n Type conversion file ¨ Stores type conversion functions to use with interface code

Example typedef struct { int a; int b; } t; t some. Ts[]; int f(t T) { return T. a of + T. b; Definition t } has been changed!! typedef struct { int a; int b; int c; } t; t some. Ts[]; int f(t T) { return T. a + T. b; }

Example typedeff struct must {also be int a; stubbed int b; as t is } t; changed t some. Ts[]; int f(t T) { return T. a + T. b; } typedef struct some. Ts must{ a; int b; int c; be int transformed as} t; t is changed t some. Ts[]; int f(t T) { return T. a + T. b; }

Example Type conversion file typedef … t; typedef … New: : t; New: : t t_old 2 new(t from) { New: : t to = new New: : t { b=from. b, a=from. a, c=0 }; return (to); } Interface file (skeleton) static void S() { int idx = 0; for( idx = 0; idx < size(some. Ts); idx++) New: : some. Ts[idx] = t_old 2 new(some. Ts[idx]); } …

Case Study: Flash. Ed Web Server n Flash. Ed: an updateable web server ¨ Based n on Flash web server [Pai et al. 1999] 12 k Lo. C (in C) ¨ Incrementally built to demonstrate their system Core part is ported first, and then several features n New features are provided in the form of dynamic patches n

Case Study: Flash. Ed Web Server Preparation n Port the original server to Popcorn ¨ Because n their system uses Popcorn and TAL And modify it to be updateable ¨ Maintenance command interface n Through which a patch is transmitted to the server ¨ Exception instead of termination n Replaced exit() with throwing an exception n Shut down and restart if the application got an exception

Case Study: Flash. Ed Web Server Application Structure main() …… select() process socket activities Process maintenance commands here Exception process new connections Shutdown Restart Event Loop

Case Study: Flash. Ed Web Server Development Timeline n Version 0. 1 (10/12/00) ¨ Initial version n Version 0. 2 (10/20/00) ¨ Added pathname translation caching ¨ Fided date parsing bug n Version 0. 3 (11/14/00) ¨ Added file cache ¨ Added new maintenance commands ¨… n Version 0. 4 (02/07/01) ¨ Added dynamic directory listing feature

Case Study: Flash. Ed Web Server Patch Amount n Total # of patches > # of changed files ¨ Because n change in type affected other files Most of interface code is automatically generated

Case Study: Flash. Ed Web Server State Transformation Problem n Impossible to fill newly added field due to lack of information ¨ For example, add creation time to structure ¨ Occurred in Flash. Ed version 0. 3 n n Data structure for file caching cannot be translated straightforwardly Modified code to allow lack of information

Case Study: Flash. Ed Web Server Performance Measurement n Benchmarking Flash. Ed web server using httperf ¨ For each version of Flash. Ed, three variants Static: no dynamic update support n Updateable: Compiled with dynamic update n Updated: updateable + apply dynamic patch n n Performance degradation is not apparent ¨ 0. 3～ 0. 9% compared to original Flash ¨ Updateability only imposes ～ 3% overhead

Case Study: Flash. Ed Web Server Overhead for Update n Measured time for updating version 0. 2 to 0. 3 ¨ Total n 14 patches, 2 type modifications Analysis ¨ 0. 01～ 0. 06 sec to link-check (checking of interfaces) ¨ 0. 81 sec to relink and state transformation ¨ 1～ 3 sec to typechecking the entire program n n Heavyweight but can be performed offline Verification is generally linear in the size of files being verified [Grossman, Morrisett 2000]

Conclusion n Designed and implemented a system to realize dynamic update ¨ Designed to achieve flexibility, robustness, ease of use and low overhead n Implemented a dynamically updateable web server Flash. Ed ¨ And measured performance and update cost