1 Dynamic Software Updating Michael Hicks Jonathan T. Moore Scott Nettles Presented by: Ruchi Gupta...
-
Upload
elinor-shelton -
Category
Documents
-
view
224 -
download
0
Transcript of 1 Dynamic Software Updating Michael Hicks Jonathan T. Moore Scott Nettles Presented by: Ruchi Gupta...
1
Dynamic Software Updating
Michael Hicks Jonathan T. Moore
Scott Nettles
Presented by: Ruchi Gupta
Ritu Varma Rohan Puri
2
Motivation & Solution Motivation
Need of applications that run continuously without interruption Need for fixing bugs and upgrading the functioning system Must be achievable at low cost, easy to use, correct, and low
overhead
Solution Dynamic Software Updating (DSU) Type-safe dynamic updating of native code in an extremely
flexible manner Implement dynamic patches Use of semi-automated tools
3
Properties of Dynamic Software Updating System Flexibility
permits changes at function granularity types of data and functions can be updated
Correctness ensured by proof-carrying code
Ease of use patch generation semi-automated
Low Overhead adding updating infrastructure has minimal overhead on
application
4
What is Dynamic Patch? (1)
5
What is Dynamic Patch? (2) State Transformer Function
used to convert existing state to a form usable by new code applied when types are unaffected
Stub function applied when types definition changes interface between the old callers of function and new
definitions
What if patch changes type of global variable? then all the code that references that data must be
simultaneously changed
6
Types of Updates Code and Data Updates
reference to existing function calls and data be redirected to Stubs and new data definitions
Updating Type Definition to preserve type-safety, there is need to upgrade type definitions as
understood by type checker used in dynamic linker.
7
Mechanism for Code and Data Updates Rewriting
at update time the running code is rewritten to refer directly to appropriate parts of patch
normal compilation, no runtime cost (except at update time)
Indirection applying the patch updates the indirection
table to point to the new function definition. simple to implements small performance penalty
8
Mechanism for Code and Data Updates - Indirection
9
Mechanism for Updating Type Definition Replacement
applying a patch replaces existing type definition with new one
care must be taken to convert existing instances also, whether in heap, stack
Renaming rename occurrence of old names with new instances of old type remains
10
Building Updateable Systems(1) HOW ARE PATCHES GENERATED
Patch construction method Compare old version with new version of code. Automatically generate the patch file Fill in the parts of the state transformer and stub functions , Adv?
Automatic Patch Generation
Identify changes to functions and data Files parsed and type checked Type definition comparison (new names for new types) Value declaration comparison
Generate stub functions and state transformers State translator code ( Global variables -changed and unchanged) Default stubs for functions that have changed type
Generator inserts statement that raises an exception Automatically generate call to new version of function
Type conversion function (example –struct)
11
Building Updateable Systems(2) HOW CAN PATCHES BE CORRECTLY APPLIED
Correct timing of update is important
E.g. new version of num will not reflect the call of f Undecidable task, has a very limited automated support If automatic then certain restrictions apply Timing enforced at compile time( software construction) rather
than at run time Adv:Implementation Complexity of update timing enforcement
avoided Disadv:System must be constructed appropriately else a costly
affair
12
Implementation (1) Framework (TYPED ASSEMBLY LANGUAGE AND SOURCE
LANGUAGE-POPCORN)
How to implement Dynamic update by reference indirection Add support to the existing dynamic linker to support dynamic updating Linker consists of trusted(C and OCaml)) and untrusted part (Popcorn)
Linking and symbol management functionality in the untrusted part Loading and verification occurs in the trusted part
At compile time all files have their external references indirected through a local Global offset table (GOT)
At link time the entries in the GOTs are tracked by the dynamic linker in Global dynamic symbol table.
For dynamic updating each GOT entry filled with the corresponding entry in the symbol table File updated –old entry in the Symbol table -> new entry Function changed type-old entry removed from table, points to stub, new entry
points to new function
13
Implementation (2)int afunc() {
return GOT.bfunc.1();
}GOT = { bfunc = };
int bfunc() {
return 1;
}
int bfunc(int a) {
return 1+a;
}
int Stub::bfunc() {
return bfunc(0);
}
Dynamic Symbol TableOld entry
14
Implementation (3)
In addition- Rebinding, Customized Linking order and Exporting static variable.
GOT only stores references to externally defined variables local references are direct. Disadv: Indirection penalty
Updates occur on files rather than procedure or individual data.Why?Adv?
Two levels of indirection used. Why?
15
Implementation (4) HOW TO DEFINE AND COMPILE PATCHES
Patch description file Implementation filename Interface code filename Shared type definitions Type definitions to rename
Interface code file Variable references w.r.t version- New::, Old:: Stub::
Compilation of patches Convert into a popcorn file All type definitions common to the implementation file and
sharing list are made externs in the implementation file The rest (non externs) are prefixed with New:: The interface and the implementation file concatenated together Mappings from renaming list -> file’s type names
16
FLASHED Web Server Event Loop for FLASH
while(1) { select( args ….); process_requests(); accept_new_connections(); }
Two changes to FLASH to make it updateable
Maintenance command interface Application connects to server and sends files. Select () processes, exits event
processing loop (to reflect any changes in the loop code). State saved.
Error Handling Original Flash calls exit(). FLASHED raises exception , prints diagnostics, resets state,
closes connections and restarts. Uninterrupted service.
17
FLASHED Web Server Evolutionary
Development.
Non-trivial changes between each version. Changes in http connection
structure
Patch files generated between each version Automatic generation /
manual glue code where required.
Version 2: pathname translation caching
Version 3: file caching
Version 4: directory listing and CGI
Initial Version
Incremental Development of FLASHED
18
FLASHED Web Server Performance overhead in
updateable FLASED is 2%-6%.
Updated FLASHED should have the worst performance out of the three models, but results show otherwise. Why?
Other performance parameters
Double indirection penalty=28% Single indirection penalty
=19% Overhead due to verifying and
linking patch files
FlashEd Throughput (Mbits/sec)20 clients
46
4748
49
50
5152
53
1 2 3
FlashED versions
Thro
ughp
ut M
bits
/sec
Static
updateable
updated
19
FLASHED Web Server
Flexibility
Dynamic Linking Developer anticipates the change Makes provisions. New code can only be added in existing
interfaces.
DYMOS Changes on per function and per module basis. Changes to
infinite loops. Adds flexibility (like FLASHED) for old code to be active
during updates. Transition at well defined points like procedure calls / object
creation.
20
FLASHED Web Server
Flexibility
FLASHED Compromise between the two approaches. Dynamic patches. Know issues to be resolved
Unchecked updates Changes to trusted code base, like verifier (had this error during implementation).
Function pointers Indirection issues. Dereference the pointers late. Store actual address not pointer.
Namespace security Users executing code. Apply policy bases on loading environment.
Updating ADTs ADTs only visible to the local file. Difficult to update. Apply environment bases rights.
21
FLASHED Web Server Correctness
Old and new code running in separate threads with the old phasing out the new.
Stopping the old code, updating it with new and running it with the old state
FLASHED approach. System is constructed such that update points are defined. Work needs to be done in determining the location of these safety points.
Ease of use FLASHED scores over current frame works. Automatic
generation of patch files with developers plugging in code where required.
Overhead As discussed in the performance section the two levels of
indirection entails very limited overhead.
22
Dynamic Software updating Relevance to Embedded software
Organic development Safety critical systems.