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

[Norman Hardy]

On 2007 Nov 27, at 3:54 PM, Jed Donnelley wrote:

> 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?

The following was one example of a policy that we supported that is  
incompatible with universal migration.
You might build an application that relies on my proprietary package.

I might trust only the computers operated by one service bureau with  
my proprietary code.
A general migration facility must somehow fail to move your  
application to another machine outside that bureau.

Indeed the idea that every Java object is serializable conflicts with  
abstraction.

Alas security policies sometimes conflict; Talk to the KGB and CIA.

When there are no abstraction issues things are easy.
I wrote a short 704 subroutine that would write registers and core to  
tape with a initial boot record.
It assumed, of course, no positioned media such as mag tape.
See (http://www.cap-lore.com/stories/Checkpoint.html).

The things about VMWare that make moving feasible are largely the  
limitations that arose when you decided to run the application on its  
own Unix platform.

Keykos has a well tested way of moving an entire system image on  
magnetic with running processes, and indeed we sometimes moved from  
one 370 model to another with incompatible disk drives.
See (http://www.cis.upenn.edu/~KeyKOS/Checkpoint.html).

A well planned but unimplemented version would have moved a system  
image via a fast circuit.
See (http://www.cap-lore.com/CapTheory/KK/RemCkpt.html)

A partly planned scheme would have migrated a lightly loaded system to  
temporarily share the hardware with another lightly loaded system.
This would allow hardware maintenance while avoiding system downtime.
This was not trivial and the plan was incomplete.