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.