[cap-talk] Another "core" principle - virtualize capabilities

[Jed Donnelley]

At 01:03 PM 1/4/2007, Marcus Brinkmann wrote:
>Hi,
>
>The main point of confusion I think is finally cleared up by this
>statement:
>
> > And, for the record ;-), I am not arguing that a single universal
> > mechanism is good enough for all applications, but that a wrappable
> > and mappable object-capability interface is sufficient for all
> > applications.  There are a variety of interfaces available within
> > that constraint.
>
>I took your previous statements to mean exactly the first of the above
>("single universal mechanism").  The reason is that I believe that
>your clarified claim above is a null-statement: With sufficient
>definitions of "objects" and "methods", all (?) systems provide
>"wrappable and mappable object-capability interfaces".
>
>Consider the Linux kernel to be a single object, for example, with
>every system call being a method.  Then clearly we have a
>object-capability interface, and it is wrappable and mappable by
>either of several methods (whole-system emulation, virtualization,
>user-mode kernels, ptrace, libc) depending on the level of mapping
>desired.

I actually think such a network "object" could be useful.  Of course
the devil is in the details.  Before I can get access to such an "object"
it would seem that the object would need to be identified with a
specific Unix user.  That is, my object could be "user:jed,
system:ungwe.pair.com".

If I had a generic Unix object interface (e.g. "system:ungwe.pair.com")
that I could invoke to "login" and receive back a system call object, that
could suffice.  If that was all Unix is capable of it, would be better than
nothing.  Better that than the application specific protocols that we have
today (e.g. ftp, ssh, http, etc., etc.).  At least then we could send users
such capabilities in protected email and such.

However, notice that there are no such network objects.  I can't
get a YURL or a wideword for such an object, much less any
finer grained objects (e.g. to a file or a directory or a process) out
of Unix systems.

The fineness of the grain provides added value (POLA, etc.).  I'd
be delighted to see competition arise for value in such standardized
network, OS, or language objects.  Given that any could be mapped
and thus available in any other context, software written for object-capability
interfaces would have a wide variety of objects to chose from.  I expect
at that point a winnowing out would happen with survival of the fittest
objects.  I'm not sure if a Unix:user:systemcall object would be among
the finalists, but perhaps so.

>You may consider this to be pedantic, but hey, I'm a mathematician
>after all.

Fine, my Masters degree is in Mathematics.  I particularly enjoy
logic and set theory.  I can identify.  I dropped out of a Math
Phd program after qualifiers but before thesis to pursue my
computer interests.  Perhaps you can appreciate that.  The
ARPA net had a great appeal in those early days (1972).

>In light of this, which parts of the discussion are you still
>interested in?

I'm sorry, but while I consider the example a mildly interesting one,
I disagree with your statement that my clarified claim above, namely

"a wrappable and mappable object-capability interface is sufficient for all
applications"

is a null-statement.  Still, I'm happy you agree that at least it's true.
I've thought this was obvious for most of my career.  However, some
people (e.g. recently on this list) have objected that such an interface
can't be made to perform well at the OS interface level.

If we can accept that such an interface can be designed to perform
well for all "system call" functions, then I believe the value in such
an interface, wrappability for higher level functions like revocation,
monitoring, remoting, responsibility delegation, etc., argues for the
use of such an interface to systems at the network, OS, and language
levels.  Unfortunately, while people may believe that they have wrappable
interfaces (e.g. even with wrappability as a design goal), until some
wrapping (virtualizing) is actually done, often times the belief turns
out to be false.  Of course I suggest network "remoting" (along the lines
of the DCCS) as an effective test case that also has the side benefit of
allowing any such objects to participate in network commerce.  Naturally
there will be pressure on such remoting mechanisms to standardize their
communication protocols - object sharing protocols.

For me such standardization pressures are all to the good.

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