1. Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating
Toshihiro YOSHINO (D1, Yonezawa Lab.)

2. References
M. Hicks, S. Nettles. Dynamic Software Updating. In ACM Transactions on Programming Languages and Systems (TOPLAS), 27(6), pp , 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 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

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

12. 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’

13. 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’

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

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

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

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

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

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

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

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 Patch Automatic Patch Generator
Inputs
Outputs

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

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

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

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

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

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

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

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

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

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

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