Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

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

3. 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

4. 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

5. Design Goals • Flexibility • 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

6. 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

7. 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]

8. 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

9. 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

10. 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

11. System ImplementationHow 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

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

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

14. System ImplementationHow 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

15. System ImplementationHow 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

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

17. t_new a = 1 b = 0 t a = 1 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; typecheck the program with: t -> struct { int a; } t_new -> struct { int a; int b; }

18. System ImplementationHow 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

19. System ImplementationHow 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

20. System ImplementationHow 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

21. 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

22. Generate a PatchAutomatic Patch Generator Inputs Outputs

23. Automatic Patch GeneratorComparing 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

24. Automatic Patch GeneratorAuxiliary 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

25. 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!!

26. 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; }

27. 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]); } …

28. 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

29. Case Study: FlashEd Web ServerPreparation • 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

30. Exception Shutdown Restart Case Study: FlashEd Web ServerApplication Structure Event Loop main() …… select() Processmaintenance commands here process socketactivities process newconnections

31. Case Study: FlashEd Web ServerDevelopment 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

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

33. Case Study: FlashEd Web ServerState 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

34. Case Study: FlashEd Web ServerPerformance 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

35. Case Study: FlashEd Web ServerOverhead 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]

36. 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