36
Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating Toshihiro YOSHINO (D1, Yonezawa La b.) < [email protected] c.jp

Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

Embed Size (px)

DESCRIPTION

Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating. Toshihiro YOSHINO (D1, Yonezawa Lab.) < [email protected] >. References. - PowerPoint PPT Presentation

Citation preview

Page 1: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

Secure Compiler Seminar 5/16

Survey: Dynamic Software Updating

Toshihiro YOSHINO(D1, Yonezawa Lab.)

<[email protected]>

Page 2: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

References

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

Page 3: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 4: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

Background

Redundant hardware requires high costExtra hardware is requiredApplication specific support is also needed

⇒ Dynamic software updatingUpdate running system without shutting down

Page 5: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 6: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 7: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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]

Page 8: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 9: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 10: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 11: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 12: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 13: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 14: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 15: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 16: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 17: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 18: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 19: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 20: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 21: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 22: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

Generate a Patch

Automatic Patch Generator

Inputs Outputs

Page 23: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 24: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 25: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 26: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 27: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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)

Page 28: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 29: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 30: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

Case Study: FlashEd Web Server

Application Structure

select()

process socketactivities

process newconnections

main() ……

Event Loop

Processmaintenance

commands here

ShutdownRestart

Exception

Page 31: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 32: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 33: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 34: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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

Page 35: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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]

Page 36: Secure Compiler Seminar 5/16 Survey: Dynamic Software Updating

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