CSE 227: Lecture 12


The topics covered in this lecture are motivation for mobile code, security concerns for mobile code, and

Motivation for Using Mobile Code

Mobile code's inevitability is based on the need for latency reduction when building distributed systems. As system performance increases, latency will increasingly become a more critical performance bottleneck. (Since memory and disk capacities and CPU performance have different growth curves, there are many other architecture problems that must be solved at the same time.)

Latency hiding -- context switching to another process when blocked on I/O (multiprocessing), context switching to another thread when instruction loads from memory has high latency (SMT), caching, and similar techniques -- keep the functional units busy, but do not help much in decreasing the time to completion. Distributed systems that are spread over geographical distances must incur speed-of-light (in appropriate media -- in fiber about 1/3 that of the speed in free space) delays, and software architectures based on the venerable remote procedure call (RPC) often suffer in performance, especially when many RPCs or message roundtrips are needed.

Mobile code permits the co-location of code and data. Rather than making many RPCs over long distances, code may migrate to the RPC server, make many local RPC calls (which are cheap and fast), and send an overall result back. By using remote execution, we pay for one message roundtrip instead of many.

Examples of today's applications that may benefit from using mobile code / remote execution are web indexing, web connectivity graph analysis, semi-real time activities such as market arbitrage or remotely robot control (e.g., planetary rovers). I conjecture that users will want to use mobile code as well, much in the same way that simple RPCs (HTTP GET may be viewed as a simple RPC; CORBA, DCOM, and .net are certainly variations/extensions of this theme) are in use by average users.

Security Concerns When Using Mobile Code

Generally server security and remote execution security (or agent security) are the two concerns.

Mobile Code Server Security

Techniques such as sandboxing with appropriate API security -- whether through SFI, interpretation, or user/kernel address space separation -- can be used to place limit on what the mobile code might do. This mitigates the risks of allowing mobile code by controlling the access of mobile code to resources such as network I/O, CPU time, temporary storage, or persistent state in the form of filesystem storage.

Policy issues such as whether mobile code must be authenticated (perhaps for greater access to resources) or may run anonymously can have an impact on mobile code security.

Mobile Code Execution Security

Once we send code to be remotely executed, we lose control over that code. If the server is not trustworthy, it can lie about the results of that computation. This is a form of integrity for computation: the server may just make one conditional branch work differently when the code runs, or it may make up the entire result. Of course, this is a risk that was present for RPC-based distributed systems, but the security model differs: in RPC systems, we typically implicitly trust the RPC server and sometimes use cryptography to authenticate the server (Sun's ``secure'' rpc, or HTTP over SSL). For mobile code systems where many administrative domains are involved, this is less clear.

The integrity property for computation is by analogy with integrity in communication security. Similarly, there is a privacy property....


[ search CSE | CSE | bsy's home page | links | webster | MRQE | google | yahoo | citeseer | certserver ]
picture of bsy

bsy+cse227w02@cs.ucsd.edu, last updated Mon Apr 8 20:19:51 PDT 2002. Copyright 2002 Bennet Yee.
email bsy.


Don't make me hand over my privacy keys!