secure compiler seminar 5/16 survey: dynamic software updating
DESCRIPTION
Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating. Toshihiro YOSHINO (D1, Yonezawa Lab.) < [email protected] >. References. - PowerPoint PPT PresentationTRANSCRIPT
Secure Compiler Seminar 5/16
Survey: Dynamic Software Updating
Toshihiro YOSHINO(D1, Yonezawa Lab.)
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 systemsEspecially 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 costExtra hardware is requiredApplication specific support is also needed
⇒ Dynamic software updatingUpdate running system without shutting down
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
Existing Approaches are not Enough
Flexibility: Many systems limit capabilitiesPossible 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 linkingNew 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)
1. 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
System Implementation
Use dynamic linking Dynamic link a patch, transform state locally and switc
h 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 f
unction after a patch is loaded
Reference indirection Store all function pointers into a global table and m
odify the table on update
System Implementation > How to Update Code?
Code Relinking Approach
int afunc() { … return bfunc();}
module Aint bfunc() { return 1;}
module B
External reference is resolved on
startup (linking)int bfunc() { return 2;}
module B’
Linking occurs again, updating all existing re
ference to bfunc()
System Implementation > How to Update Code?
Reference Indirection Approach
int afunc() { … return bfunc();}
module A Indirection table
int bfunc() { return 1;}
module Bint bfunc() { return 2;}
module B’
External references are indirected with t
his tableOverwriting the table makes functions calls
redirected to new code
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 approachesReplacement
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
System Implementation > How to Update Type Definitions?
Replacement Approach
typedef struct { int a;} t;
typedef struct { int a; int b;} t;
t a = 1
t a = 2
t a = 1b = 0
t a = 2b = 0
typecheck the program with:
t -> struct { int a; int b; }
System Implementation > How to Update Type Definitions?
Renaming Approach
typedef struct { int a;} t;
typedef struct { int a; int b;} t_new;
t a = 1
t a = 2
typecheck the program with:
t -> struct { int a; } t_new -> struct {
int a; int b; }
t_new a = 1b = 0
System Implementation
How to Update Type Definitions?
They chose renaming hereReplacement is complex to implementWithout 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 codesFind modified filesCompare 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 createdRename 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 fileStores type conversion functions to use with i
nterface code
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;int c;} t;t someTs[];int f(t T) { return T.a + T.b;}
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;}
someTs must be transformed as t is changed
f must also be stubbed as t is
changed
Example
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]);
}
…
Type conversion file Interface file (skeleton)
Case Study: FlashEd Web Server
FlashEd: an updateable web serverBased 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
select()
process socketactivities
process newconnections
main() ……
Event Loop
Processmaintenance
commands here
ShutdownRestart
Exception
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 l
ack of informationFor example, add creation time to structureOccurred 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
httperfFor 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 apparent0.3 ~ 0.9% compared to original FlashUpdateability 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 verifie
d [Grossman, Morrisett 2000]
Conclusion
Designed and implemented a system to realize dynamic updateDesigned to achieve flexibility, robustness, ea
se of use and low overhead Implemented a dynamically updateable we
b server FlashEdAnd measured performance and update cost