CSE 227: Lecture 12
The topics covered in this lecture are
motivation for mobile code,
security concerns for mobile code,
and
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.
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
]
bsy+cse227w02@cs.ucsd.edu, last updated Mon Apr 8 20:19:51 PDT 2002. Copyright 2002 Bennet Yee.
email bsy.