[cap-talk] Restricted execution environments, virtual machines, capabilities

Jed at Webstart donnelley1 at webstart.com
Sat Dec 11 00:01:08 EST 2004


At 09:57 AM 12/10/2004, Norman Hardy wrote:

>On Dec 7, 2004, at 12:51 PM, Jed Donnelley wrote:
>
>....
>>Does anybody know if there's a commonly accepted name for such a
>>facility?  I spent some time looking at system calls for Unix (easier than
>>Windows it seems to me) such as fork, clone, vfork, and execve, but
>>I didn't find what I was looking for.  clone seems to come closest, but
>>I couldn't find a flag that would allow the cloning process adequate
>>control over the cloned process.  Presumably there's a way to do this
>>as I would think wine would need such a facility.  The wine documentation
>>seems to suggest that it uses "clone", but I don't see how.  Does anybody
>>have any experience in this area and might be able to point me in the right
>>direction?  I can probably get such information from a wine list if need
>>be.

>The original restricted execution environment is "problem mode" in
>the two state machine.
>See <http://cap-lore.com/CapTheory/TwoState.html> for a short note on
>the connection.
>There are many ideas to by transported once this analogy is made.

Of course what you there call "problem" and "privileged" modes
is a common mechanism for allowing an OS to protect itself from
user applications and to effectively multiplex the resources on
a computer.  It's essentially the same basis on an x86 as I
understand it.

What I'm looking for is a feature in a multi-user OS where I can
run a process, but not in the normal ambient (user) authority
mechanism that the OS supplies.  I want the OS to allow the
process to execute ordinary user instructions, to be time shared
and paged/swapped as usual, *but* I don't want the OS to
interpret any system calls for the process or handle other
"faults" (e.g. divide by zero, invalid memory reference, etc.)
for it.  Instead I want the OS to tell "me" (a monitoring
process) what happened so I can do whatever I want to
the process.  In particular I want to be able to interpret
capability invocations so I can limit the process to POLA
access.

Interestingly the LTSS operating system (that you know Norm,
but most others I expect do not) had this sort of a feature.
It was somewhat complicated by the "exchange" mechanism
available on Cray systems in that it was called something
like "Run this problem program in my memory space" and
was initiated with a pointer to an "exchange package".
The OS filtered that exchange package, checked and
translated memory bounds, etc. and then "exchanged".

When the subsidiary process caused a trap, control was
transferred back to the monitoring process with the exchange
package indicating what happened.

Our first implementation of the NLTSS operating system
ran as a user process on LTSS and ran "problem" programs
under itself by using that mechanism.  We were able to
support the one NLTSS system call (very simple
system ;-) just fine..., though we were no where near
able to support something as complex as a virtual
machine monitor.

I believe such a facility is quite easy to supply on
any OS.  It's *much* simpler than supporting a
virtual machine because you don't have to deal with
virtual privileged mode, interrupts or masking them,
I/O (however it is handled), etc.  It's just like an ordinary
user process *except* the OS doesn't interpret any
system calls for it (e.g. according to "ambient authority")
but instead just reports what happened to the monitoring
process (e.g. like Polaris).

With such a facility I believe one could build a POLA
execution environment much like I described in:

http://www.eros-os.org/pipermail/cap-talk/2004-December/002603.html

Of course instead of running an emulator for an existing
OS in the restricted execution environment one could
also make the environment look like, say, EROS,
and run native EROS programs.  That way the encapsulation
would only be a single level.

The main idea of the mechanism is to provide that base
POLA environment (as Polaris attempts to do) on one
of today's market leading OSs.  To make it practical
you need to have practical programs to run in that
environment.  That's why I suggest running an
emulator for a market leading OS - like Windows or
OS-X or Linux - inside the POLA restricted execution
environment.  Then there can be any complexity
in the emulator and in the application and there is
no danger that any bugs in that software can violate
the base POLA restriction placed on the environment
at startup and as extended by things like Polaris'
open file dialogs and such *in the base OS*.

With such a mechanism the effective sharing still
happens through the base OS (e.g. network communication,
file sharing, etc., etc.), *but* all the applications that
run under the restricted execution environment,
including those native applications for market leading
OSs, are restricted to POLA.

I guess you can tell the notion appeals to me ... ;-)



More information about the cap-talk mailing list