[cap-talk] Moving running applications (was: Kernels at Microsoft)

[Jed Donnelley]

On 11/26/2007 6:58 PM, Jonathan S. Shapiro wrote:
> On Mon, 2007-11-26 at 18:39 -0800, Jed Donnelley wrote:
> 
>> If you don't have access to the above then I believe you
>> can't move a running application.  A place where you
>> are likely to have the above is with a user "shell"
>> that initializes processes on behalf of a user.
>> Such a 'shell' should have the authority necessary
>> to move a running application - even in KeyKos
>> I believe (no excuses ;-).
> 
> No. In KeyKOS/EROS/Coyotos an application is entitled to hold state that
> it does not directly disclose to its wielder. The fact that some user is
> billed for the storage gives that user authority to rescind the storage,
> but it does not give that user the intrinsic right to inspect that
> storage.

Is this a decision for the application or the application
"wielder" (creator/shell)?  If the decision isn't available
to the application creator then it seems that KeyKOS/EROS/Coyotos
is designed so as to make process migration impossible.
As Bill Frantz says, there is apparently no "place to stand
to get to all the state of the application.".

That seems unfortunate from the viewpoint of moving a
running application, but perhaps this isn't so important?
I imagine you feel that this lack is more than compensated
for by additional security/integrity?

If I create a process for running programs and I
assemble all the state to initiate the running of a
process then it seems reasonable to me that I
have access to all the subsequent state - sufficient
for moving the process.

If you'd like to take up the discussion about execute-
only programs and their integrity, that might be a
reasonable direction to split this thread - if there
might be anything new to discuss.  If this issue is
the basis for the KeyKOS/EROS/Coyotos restriction
on process state access, then perhaps this can be
seen as the trade-off against which we can weight
the ability to move running applications?

On 11/27/2007 3:36 AM, Jonathan Smith wrote:
> An historical perspective:
>
> "A Survey of Process Migration Mechanisms", by J. M. SMith, in ACM OS
> Review, pp. 28-40, July 1988.

is a bit dated, but an interesting read.  Of course I
remember many of those systems, particularly DEMOS - which
gets a lot of attention in that paper.

My earlier comment about a capability interface being
an effectively parsimonious and location independent
point around which to more a running application is
somewhat anticipated by this discussion from the
above paper:
______________
The introduction to the paper [Powell1983a]
describing DEMOS/MP's process migration scheme
makes the following observation:

"Process migration has been proposed as a
feature in a number of systems, but successful
implementations are rare. Some of
the problems encountered relate to disconnecting
the process from its old environment
and connecting it with its new one,
not only making the the new location of
the process transparent to other processes,
but performing the transition without
affecting operations in progress. In many
systems, the state of a process is distributed
among a number of tables in the system
making it hard to extract that information
from the source processor and create
corresponding entries on the destination
processor. In other systems, the presence
of a machine identifier as part of the
process identifier used in communication
makes continuous transparent interaction
with other processes impossible. In most
systems, the fact that some parts of the
system interact with processes in a
location-dependent way has meant that the
system is not free to move a process at any
point in time."

This observation gives us some insight into the
reasons why port or message based systems (such as
DEMOS/MP and Stanford's V system) implement process
migration more easily than other system designs.
___________

Tying this back to Norm's initial comment, I believe
this limiting of the interface makes the capability
invocation interface a more natural "cleavage" point
for application migration than is the Virtual Machine
interface (with it's necessary devices including
networks).  I don't believe any differences between
"port" designs vs. object/capability designs are
relevant to this discussion, but of course I'd
be interested to hear the thoughts of others
on this topic.

However, if this historical document is any indication
as to the value and current state of process migration,
I'd say there isn't too much reason to worry about it
at this point - as intriguing as the topic might be.

The narrow migration of serving VMs from one platform
to another on the same LAN does seem to me to have
practical value, so in so far as that is accomplished,
perhaps some value will be achieved in this space.

--Jed  http://www.webstart.com/jed/