[cap-talk] - Bellizzomi - Capabilities and Shapiro's focus, Coyotos, etc.

Jed at Webstart donnelley1 at webstart.com
Tue Nov 28 18:44:42 CST 2006


At 03:38 PM 11/28/2006, Valerio Bellizzomi wrote:
>On 28/11/2006, at 13.49, Jed at Webstart wrote:
><snip>
> >At this point I personally think any such efforts <to block wall banging>
> >are likely a waste of time and effort.  I believe that the only way to deal
> >with wall banging (which effort is in itself likely not a good use of time)
> >is to limit shared resources.  I think the 
> trade-offs are clear in this area.
>
>I believe limiting shared resource is one of the objectives of Shap's
>research (read the "Debunking Linus's Latest" and "From EROS to
>Coyotos/BitC: Open Source meets Open Proofs" papers). I think we have to
>sit down and wait that Coyotos is ready for prime time. Meanwhile I
>continue to learn BitC at least theorically, until I put myself in
>condition to build the compiler (which means installing FC6 and the
>Coyotos development tree on a new machine) and start programming.

I believe I've read enough from the above papers and from:

"Verifying the EROS Confinement Mechanism"

to convince myself that Jonathan Shapiro is not addressing wall
banging with at least EROS and likely not with Coyotos (though
as they say 'I'm all ears' - I'd love to see a solution in that area).

In "From EROS to Coyotos/BitC: Open Source Meets Open Proofs"

he says:
_______________________________________________________
The Coyotos effort inherits two useful successes
from the EROS effort:

    A verification proof that the architecture can en-
    force a security property known as “confinement.”
and ...
_______________________________________________________

but then in "Verifying the EROS Confinement Mechanism" he says:

"In this paper, we will ignore issues of covert channels.  While important,
reducing such channels is of interest only when it has been shown that overt
channels have been closed."

Perhaps we'll hear from Jonathan if I've got the above wrong.

> >We (the capability community) have to make convincing arguments,
> >demonstrations, etc. in this area to swing 
> people over to our position (or not...).
>
>I'm not a fan of pure theoric demos,

I agree.

>I think we should start using capability systems in our daily work,

That's what wideword, CapWiki, and many more URLs as
capabilities are.  They are in daily use and increasing.  I believe
they form the foundation for a capability based IT sharing
infrastructure.

>and then show that they really work very well for us. This would
>be the better demonstration we can do.
>
>val

Given what you said above I fear you are referring to Coyotos or
some other OS (e.g. research) implementation.  Unfortunately
I used capability OSs to good effect for some 20 years
(~1972 - 1992) and they really worked for us.  That didn't help
things any as after that capability systems effectively disappeared
(e.g. KeyKOS, NLTSS, Amoeba and variants, Monash, etc., etc.).
Perhaps you will understand why I'm not very optimistic about
that approach.  Still, I wish it success and am glad that many
approaches are being pursued.  In some ways efforts at the OS
level and at the network level and even at the language level are
complimentary.  Unfortunately the work at the OS level seems to
stay in the R&D/academic community where Butler Lampson's
statement still seems to hold:

"Capability based systems are the way of the future—and they
always will be."

Sure I know of many of the commercial projects and even
products based on capabilities (e.g. going back to the
Plessey 250), but such systems (hardware and software)
have been and continue to be commercially insignificant.

I'm more hopeful for change sooner at the network level.
Hey, I hope object/capabilities at some point become the
next "big thing" from networks to OSs to languages.  That
would finally prove Lampson wrong.  We have a ways to go
before we're at that point.

Please don't oversell capabilities and suggest that they can
solve covert channel problems like wall banging.  I think it's enough
to deal with overt communication channels as Jonathan suggests.

The rest is mostly details for Val - can probably be ignored by others:

><snip>
> >I consider the above a nit:
> >
> >1) In information technology as elsewhere, a nit (pronounced NIHT) is
> >a small, usually unimportant imperfection in something. People who
> >have unusually high or unreasonable standards for the quality of a
> >thing are sometimes referred to as nitpickers.
>
>It is a question of standpoints, define "unreasonable".

Let me see if I have this straight.  You want me to justify why
I consider an issue (how/whether a user's shell lowers and/or
raises it's authority when the user goes through various states
of activity on a connection) a nit?  Now we're talking nits on nits?
Even I won't write that much email ;-)

> >>I was suggesting to make the login process strictly tied to the
> >>kernel model of operation.
> >
> >I'm afraid I still don't understand what you mean by the "kernel model of
> >operation."
>
>The meaning is Atomic action kernel: setup phase -> commit point -> action
>phase.
>The action phase either succeeds entirely or fails entirely, this is the
>notion of "atomic" as Shap defines it.

Fine.  I don't see what the term "kernel" adds to the notion of an atomic
operation, but I don't think it matters.

><snip>
> >Proxying is a means to do sharing.  Copying data does no "sharing"
> >as I was describing above (shared access).  I'm not sure where we're
> >going with this thread.
>
>You said copying isn't like sharing because you can't read future changes,

Right.

>so proxying isn't sharing.

No, I don't agree.  Proxying is a type of sharing.  A copy happens
once.  A proxy happens for some extended time.

>I agree, but now you say that proxying is a
>means to do sharing, you need to pick a consistent position here.

The above sounds like mostly email flap to me.  However, I do say
that proxying is sharing.  It allows future access - through the proxy.
That's what sharing access to a resource is.





More information about the cap-talk mailing list