[cap-talk] Capability levels

[Jed at Webstart]

At 04:54 PM 8/16/2006, David Hopwood wrote:
>Jed at Webstart wrote:
> > At 10:02 PM 8/15/2006, David Hopwood wrote:
> >
> >>... we need to identify and fix any
> >>limitations of E's capability model that prevent it from being extended
> >>to the OS level as well.
> >
> > To me the above "extend" is the key to what I regard as the 
> relevant levels.
> >
> > You "extend" the language level capabilities (e.g. E's) to the "OS"
> > level (what I consider the IPC level).
>
>Right; this is extending them to a lower level ([1] in the diagram below).
>...
>I'm still confused as to what exactly you mean by "level", and why you're
>calling it that.

"Extension" to me implies to a level of broader scope.  I tried to explain
this more later in the message, but you didn't respond to those later
comments.  Let me try with another diagram to illustrate what I mean
by scope and level:

level                                  implementation

high                    network - can communicate anywhere

lower IPC       IPC1 (only within IPC1)              IPC2 (only within IPC2)

language   (shared language  (L2) (L3)        (shared language (L2) (L3)
             within a process)                  within a process)

A language implementation can only interoperate as far as the language
mechanisms extend - certainly within a program all within the language
and perhaps to other comparable languages through shared mechanisms
for parameter passing, etc.

A language mechanism can in principle be "extended" to a broader scope,
higher level, by a mechanism that allows its capabilities to be communicated
through an IPC mechanism on a system.

A capability communication mechanism implemented though an IPC
scheme can interoperate anywhere the IPC scheme is supported,
usually within a single system , SMP, or tight cluster.  Whether it's
the extension of a language mechanism or defined as a base mechanism
in it's own right (perhaps adapted at the language level), it has the scope
of communicating process to process where in principal the processes
can be implemented in any language.

A capability communication mechanism implemented at the network
level can interoperate anywhere on the network across administrative
domains and across any sort of IPC mechanisms for communicating
capabilities - whether it's an extension of an IPC based mechanism
(e.g. as the DCCS is) or some native network level capability communication
mechanism.  It may be possible to adapt or make visible network level
capabilities (e.g. think YURLs) at an IPC level or even as low as at the
language level, but in both cases the scope of their access is reduced
in their lower level representation.

>BTW, "IPC" begs the question of what is considered to be a "process".
>All capability communication is "IPC" for some "P". The distinguishing
>factor at the OS level is that we are communicating between OS processes.

I agree.  This is the reason I was suggesting that the difference between
the "process" notion (generally a register set, virtual memory map,
perhaps a c-list, etc.) and an "active object" (generally a running instance
of a method, perhaps a stack, but with a language/library level
implementation - more like a thread or task) is relevant and important
at this level of discussion.

Whatever term you use, what's visible to the OS (scheduled unit,
heavier weight) necessarily has broader scope - and thus I argue
a higher level - than what's implemented at the language level.

> > You "extend" the OS/IPC level capabilities to the network level.
>
>Nope; you extend the language capabilities upward to the network level [2].

Isn't that what I said?  For me "extensions" (broadening scope) are always
"up".  Just to have another term, above I used the term "adapting" for the
way one can represent something like an IPC level capability at the
language level or a network capability at the IPC or language levels.
Such "adaptations" however, necessarily result in reduced scope and
I therefore argue a "lower" level.

>Skipping the language level, i.e. proxying capabilities for OS objects
>directly over the network, is also technically possible.

That's exactly what the DCCS did (e.g. see the transparent extension
discussion in response to MarkM's message).  There was no need
to "skip" any language level because the language level was considered
below the IPC level - reduced in scope to within a process.

>However, when aiming
>for a system that supports all three levels, this is not the 
>simplest approach,
>nor is it any more functional or more efficient. Since the network protocols
>are implemented by code at the language level,

as are the IPC level protocols.  However, in both cases the implementations
are manipulating representations rather than capabilities themselves.

>it is simpler to make them
>proxy language objects. Such objects can in turn be proxies for OS objects,
>and so you only need two "extensions" rather than three.

I think we're saying the same thing using different words.  In terms of
the scoping (network widest, IPC next widest, and language narrowest),
I believe you only need two "extensions" in any case.

Perhaps we need to crank down a bit on the terminology.

A mechanism like the DCCS where an IPC level capability communication
mechanism is transparently extended across a network I believe deserves
to be called an "extension".  From the viewpoint of the processes invoking
or delegating capabilities, they can't tell that the network 
extension mechanism
is in the middle.

Similarly one could imagine "extending" a language level object-capability
mechanism (e.g. that in E) to an IPC level or even to a network level in
a transparent way - so that active objects invoking objects were unaware
that the active objects servicing their requests could be executing in some
other system across a network.

When going in the other direction, what I call "adapting" above, there are
very different issues involved.  For example, consider "adapting" a network
capability mechanism like YURLs to an IPC implementation like the CCS
(consider DVH or KeyKOS or EROS).  How would one do that?  You could
of course create an "object" for each network level capability (YURL)
adapted.  You could imagine an invocation on such an object somehow
doing a comparable invocation at the network level.  However, what
happens if some process at the IPC level invokes one of the IPC
level representations for a network capability and tries to pass it
another IPC level capability?  Does that simply produce an error?
What if the capability happens to be another IPC level representation
of a network level capability and the intent was to delegate that
capability to through the invocation of the IPC level representation of
the network capability.

What a mess!  I think the same issues arise if one tries to "adapt"
IPC level capabilities to the language level or network level capabilities
to the language level.

When extending lower level capabilities "upward" the extension can
be done invisibly and transparently (except for performance), but
at each level if one looks inside the protocols appear rather ad
hoc and specific to the lower level mechanisms.  I was quite sensitized
to this issue when I published RFC 712 suggesting the  DCCS protocol
for the ARPA network.  When looked at from the viewpoint of the network
that protocol looked rather ad hoc and system dependent.  I can well
understand why it didn't make much sense to anybody.

Let me focus on this diagram for a minute:

>      <--------------// - - - - - - - - - //----scope---->
>       Network cap   |                      Network cap   |
>  ^    protocol in   |                      protocol in   |
>  |    process 1A    |                      process 2A    |
>[2]  ===============|                     ===============|
>  |    <---scope---> |  <---scope--->       <---scope---> |
>       Cap language  |  Cap language        Cap language  |
>  |    in process 1A |  in process 1B       in process 2A |
>[1]  ================================    ================================
>  |   <-----------scope------------>      <-----------scope------------>
>  v        Cap OS for machine 1                Cap OS for machine 2

where you suggest the scope of the language level capabilities lies
between the OS/IPC level and the network level.  As you show above,
the scope for the language capabilities is limited to within the
processes.  So the scope may be process 1A or process 1B or
process 2A.  At the IPC level the scopes are broader, for machine 1
or machine 2.   When you get to the network level then isn't the scope
still broader?  Isn't it The Network?  Doesn't The Network bind
together machine 1 and machine 2 into a broader scope.

I don't care of course where you put the top and bottom, but shouldn't
the above diagram look more like:

[2]  ===============|                     ===============|
  |    <---scope---> |  <---scope--->       <---scope---> |
       Cap language  |  Cap language        Cap language  |
  |    in process 1A |  in process 1B       in process 2A |
[1]  ================================    ================================
  |   <-----------scope------------>      <-----------scope------------>
[0]  ====================================================================
  v        Cap OS for machine 1                Cap OS for machine 2
      <--------------// - - - - - - - - - //----scope---->
                                                    Network Cap
?

> > At each extension you get broader scope.  I consider that broader
> > scope a higher "level" - a higher capability level.
>
>I'm still confused as to what exactly you mean by "level", and why you're
>calling it that.
>
>I've explained that what I mean by "level" is the same thing as meant
>by Dijkstra in <http://www.cs.utexas.edu/~EWD/ewd01xx/EWD196.PDF>.

It's been a while since I've read that paper.  However, I just did so to remind
me of what was there.  I love this reference:

"At the moment of writing the testing is not yet completed, but the resulting
system will be guaranteed to be flawless."

Why isn't that happening today ;-)

However, getting to your point about the levels as used to describe
(modestly enough) THE programming system, they are:

Level 0 - switching between scheduled processes ("alternator")
Level 1 - the "segment controller" - what I believe we would now call paging
Level 2 - the "message interpreter" - which seems to be a key stroke 
interpreter
Level 3 - device buffering
Level 4 - independent user programs
Level 5 - the operator

I'm not quite sure how to apply that description to our 
discussion.  It seems to
me the above levels are mostly focused on the "can interrupt" 
relationship - where
lower levels can always interrupt higher levels and not visa versa - 
though it does
seem a bit odd to me that key stroke interpretation would appear 
lower than device
buffering.

Regardless, perhaps you can describe for me how to map the above to 
our discussion
of capability levels.

> >... In some
> > ways I regard the additional flexibility at the IPC level and even
> > more flexibility at the language level as liabilities.  They allow
> > mechanisms to be added that can (in my view) corrupt the base object
> > capability model and introduce features that are difficult or
> > impossible to extend to the next higher level.
>
>Which features?

What I was considering explicitly is a "feature" like blocking of
delegation (e.g. as with DEMOS and Mach also as I recall
and even CapDesk if I remember one of Alan's comments
correctly), but one could consider many others - e.g. the
shared memory communication used in Mach, the limitations
on the number of communicated capabilities per invocation or
the sizes of invocation messages in systems like DVH and
KeyKOS, etc.

>The models that are being advocated for the language
>level by me, MarkM, and others, and for the OS level by Jonathan
>Shapiro and others, are very "pure" capability models that have as
>little mechanism in the security kernel as possible.

I expect you will agree that in some sense the amount of "mechanism"
is an implementation detail.  What's important is the interface.
Just consider the two levels above, the language and OS levels.
I assume the only interface available is an "invocation" at both
levels and any invocation can communicate data and capabilities
in both directions?  Is that right?  How much data?  How many
capabilities?

>The main features being advocated for the OS and language levels that
>cannot be implemented in an open network, are confinement-related
>features: auditing, the Factory mechanism, etc. Here, the fact that we
>can only instantiate a confined or audited process on a single machine
>does not seriously interfere with partial network transparency.

What is the "Factory mechanism"?  It sounds like one of the sorts of
"features" that I was considering as a liability above?  Was there a
"Factory mechanism" in DVH?  I don't recall it.

>...
> > I think it's important to ask and answer questions such as:
> >
> > "What's wrong with a network level implementation?"  (e.g. password
> > capabilities like YURLs).
>
>I will answer separately (probably as a reply to one of your previous
>posts) why a password capability representation is not appropriate at
>the language level.

as did MarkM and I think we're picking that up as a separate thread
"transparent network".

However, I admit that I'm starting to wonder if an email discussion
of these topics is going to be effective.  I wonder if some face/whiteboard
time (e.g. at HP) might be helpful.  Perhaps that won't be possible for
you David, but maybe some of the HP group could straighten me
out or I could straighten them out.  At least we could have a more
interactive airing on the "levels" and network transparency topics.

Incidentally, I notice that I can't ping or otherwise reach www.eros-os.org
at this time (21:00 Pacific).  Might that system be down or otherwise
disconnected?

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060816/d3a46a0b/attachment-0001.html