Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

1
Secure Compiler Seminar 5/16Survey Dynamic
Software Updating

• Toshihiro YOSHINO (D1, Yonezawa Lab.)
  lttossy-2_at_yl.is.s.u-tokyo.ac.jpgt

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
System Implementation gt How to Update Code?Code
Relinking Approach
Linking occurs again, updating all existing
reference to bfunc()
External reference is resolved on startup
(linking)
13
System Implementation gt 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
System Implementation gt How to Update Type
Definitions?Replacement Approach
typedef struct int a t
typedef struct int a int b t
typecheck the program with t -gt struct int
a int b
17
System Implementation gt 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 -gt struct int
a t_new -gt 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 Newt Newt
t_old2new(t from) Newt to new Newt
bfrom.b, afrom.a, c0 return
(to)
static void S() int idx 0 for( idx
0 idx lt size(someTs) idx)
NewsomeTsidx t_old2new(someTsidx)
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
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 gt 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.30.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.010.06sec to link-check (checking of
  interfaces)
• 0.81sec to relink and state transformation
• 13sec 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