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

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

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

Background 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 Flexibility Robustness Ease of use Low overhead Any part of a program should be upgraded Robustness Minimize the risk of errors and crashes due to an update Ease of use Make system simple Low overhead Making a program updateable should impact its performance as little as possible

Existing Approaches are not Enough Flexibility: Many systems limit capabilities Possible to add new code, but not to replace Hot-slide in ML [Appel 1994] 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 Dynamic C++ [Hjalmtysson, Gray 1998] cannot change types of functions and values

Existing Approaches are not Enough 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 Ease of Use: Many systems rely on uncommon programming language DYMOS [Lee 1983], Argus [Bloom 1983], etc. Low Overhead: Some systems impose high runtime overhead Due to implementation complexities, interpretation Type-safe dynamic Java classes [Malabarba et al. 2000]

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

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

System Implementation 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 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? Two major ways Code relinking The rest of the program is relinked to call the new function after a patch is loaded Reference indirection Store all function pointers into a global table and modify the table on update

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

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

System Implementation How to Update Code? They chose code relinking Does not impose extra overhead Reference indirection indirects all function calls, so it affects performance Implementation can be simple 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? Again, two major approaches Replacement State transformer transforms all data in old types on update Renaming Data in old types and new types are intermixed State transformer or stub functions translates old data when needed

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

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

System Implementation How to Update Type Definitions? 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 It must be assured in some means that the system transformed all the instances

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

System Implementation How to Trigger Update? They chose invoke approach Interrupt is difficult to realize Programmer must specify the conditions under which a module is updateable 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 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 Finding what is modified and how it is modified

Generate a Patch Automatic Patch Generator Inputs Outputs

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

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

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

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

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

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

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

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

Case Study: FlashEd Web Server Development Timeline Version 0.1 (10/12/00) Initial version Version 0.2 (10/20/00) Added pathname translation caching Fided date parsing bug Version 0.3 (11/14/00) Added file cache Added new maintenance commands … Version 0.4 (02/07/01) Added dynamic directory listing feature

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

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

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

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

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