[cap-talk] the prize - objects and their behavior, EQ?
jed at nersc.gov
Thu Oct 21 17:28:18 EDT 2004
At 04:37 AM 10/19/2004, Jonathan S. Shapiro wrote:
>On Tue, 2004-10-19 at 04:48, Ian Grigg wrote:
> > If the prize is
> > _secure resource sharing within computers and across the network_
> > then it should be writ large and loud. Is that it?
That is "IT" in my opinion. I'll elaborate a bit below, not so much on
why I feel secure network resource sharing is important (that value
should stand on its own), but why I feel that designing a local
system to be faithful to and support network resource sharing
(at least the "insertion property" discussed below) is so important.
At 04:37 AM 10/19/2004, Jonathan S. Shapiro wrote:
On Tue, 2004-10-19 at 04:48, Ian Grigg wrote:
> > Are there other opinions?
> > This is the first time I recall seeing a mission or
> > a goal of caps. Probably there are many other comments
> > along these lines, and I've missed them.
>I think that there are at least two missions. Jed seems to be focused on
>the mission above, but the emphasis of his attention appears to be on
>the "across the network" part. My view on this is well known: I'll think
>about secure distributed systems when I know how to secure a single node
>However, the two problems are complementary, and *ought* to meet in the
I think perhaps this is the best place to inject what I see as the value
of designing local systems with what I would call "network discipline".
When designing a descriptor based capability system for a single
shared memory system (e.g. up to an SMP) one has a fair amount
of flexibility in the system design. In some ways I believe this
flexibility can lead to inadvertent errors in domain
A simple example that's familiar to me is that dealing with our
consideration of extending the RATS system:
C. R. Landau "The RATS Operating System,"
Lawrence Livermore Laboratory, Report UCRL-77378 (1975).
across a network via the proxy mechanism discussed in:
We were unable to actually implement this extension for the
base RATS file object because of a seemingly minor
interface issue in the operation of the RATS file object. I
think it worthwhile describing this problem as I expect
the same sort of problem would be likely in extending
other descriptor based systems to a network. The RATS
system was designed and implemented by Charlie Landau
who is active on this list, so perhaps he can correct any
errors I might make in this discussion.
The RATS system was a virtual memory system and had
a file object with the usual reading and writing operations.
However, there was also a call on a file object that allowed
a process to "map" a portion of a file into its memory space.
On the surface of things this would seem a natural interface.
An alternative interface would be to have a call on a process
object (for the process who's memory was to be mapped)
that passed in the file to be mapped (along with indicators
as to what portion of the file to map into what portion of the
processes memory space, etc.).
The second of the above alternatives extends naturally to
a network. The first can't be so extended.
One need not go fully to a network communication mechanism
for object access rights to achieve the "network discipline" that
I am arguing has important value. I believe it suffices that
all object accesses support what I referred to in:
as the "insertion property" - terminology adapted from:
F. A. Akkoyunlu, et. al., "Some Constraints and Tradeoffs in the Design
of Network Communications," Proceedings of the Fifth Symposium on
Operating System Principles, 1975, Vol. 9, No. 5, pp. 67-74.
I don't see any recent uses of that phrase in a Google search.
Perhaps there is a more modern term for this concept? As I
note in the DCCS paper, this property requires that:
"...a process can always be transparently inserted between a serving
process and a requesting process."
This is a fairly weak constraint. It doesn't even really restrict
"side effects". It just requires that any communication through
the object interface can be supported for any process inserted
between the requester and server. When considered from a
network perspective it supports the notion that a process anywhere
on the network can be so inserted.
As can be seen in the above example of the RATS file invocation
to map memory, another process that is in effect proxying file
object calls finds itself at a loss to be able to do the necessary
memory mapping because it doesn't have the needed rights to
the process that made the request on the file object.
If on the other hand the request was on the process capability
for the process that wanted to have its memory mapped, passing
in a file capability to be used to read and write data, then the
insertion property would be satisfied and both the file and
process objects could be extended to a network.
At 04:37 AM 10/19/2004, Jonathan S. Shapiro wrote:
>That having been said, let me try to explain why Jed's model and my
>model are not perfectly congruent -- or rather, why the network model
>and the local model are not perfectly congruent.
>The question is: ``What is an object?'' As I'm sure you know, this is a
>question that will be debated until the last language designer in the
>universe finally goes to the fire. Ultimately, this comes down to: does
>the language support 'eq' (equality by pointer equality, therefore a
>reified notion of object identity).
For me the language issue is almost entirely extraneous.
Any resource protection/communication mechanism must
be independent of language. Certainly one must be able to
load multiple object modules from different languages. As
I have noted earlier I consider any language enforced protection
mechanisms as immediately suspect. They may be useful
for helping to keep a programmer from making mistakes and
pointing out those mistakes (e.g. array bounds checking), but
they can not be safely depended on for protection or security.
>...EQ? operation into the design.
>If the answer is "no", then objects are defined entirely by their
>behavior in response to messages that you send them. In such a system,
>the definition of object equality is "behavioral equivalence." In this
>class, the semantics of objects are somewhat cleaner and remoting of
>objects becomes quite easy, because messages can be serialized by the
>runtime and object descriptors (capabilities) can be indetectably
>I would be very interested to hear Jed's thoughts on how EQ? should be
>defined between proxy capabilities and local capabilities.
I don't fully understand what you are getting at with regard to the
notions of "EQ" that you refer to. I think Charles Landau started
to address some aspects of EQ in a later message. For comparison
you might find it relevant to compare the "equality" operations that the
Distributed Capability Computing System needed. It needed:
1. The ability to compare two capabilities (in its case in a processes
c-list) for absolute equality (i.e. the pointed to the same object,
with the same rights, served by the same server), and
2. The ability for a process that has created a proxy (extended)
capability to determine whether a capability was one of the capabilities
that it itself services, and if so which one.
You can see how these aspects, that I consider somewhat
important details, work out in the diagramed DCCS
implementation description in the above paper.
Perhaps it would be worthwhile working out the details
of just what sorts of comparison operations are needed
for object access rights as capabilities. Maybe continuing
the thread that Charlie picked up on might be the best way
to proceed there.
However, before I careen off in that direction, I'd like to try to
bring "the prize" back into a bit of focus by asking the following
A. In any operating system design, isn't it important to
be able to support a larger OS as a cluster on a LAN?
As long as the LAN doesn't support direct memory access
(machine pointers across the network between SMP nodes)
then I think to support such an extension one will run into
all the relevant issues for passing capabilities across the
network - including the relevant trust issues. In contemplating
such an extended design you might find yourself thinking,
the code on that system across the LAN is really just another
part of me. I.e. it' a "TCB." Being so I can trust it to do
a, b, and c. I argue that in doing so you violate POLA.
That is, with proper design there is no need to trust another
such part of your own code at the level of the underlying
communication of rights any more than to trust any other code
anywhere on the Internet. Certainly you may find reason to
assign more trust to some process/codes with the use of
specific rights that are communicated to them. However,
I argue that the assigning of any such trust should be
handled at the level of communication rights (capabilities)
and not at some lower level.
B. No matter what sorts of descriptor based rights
communication is available, other rights communication
based on the ability to communicate data will always
be available to processes - within a single OS or
across a network (where such mechanisms may be
the only option). Why not face up to this fact and
define a resource sharing protocol using this underlying
base ability to communicate data that will then suffice
for both the local and remote cases and attract use
because of its effectiveness (e.g. rather that force use
because of its exclusivity)?
Related is the following that I feel has the most focus for
C. What's "wrong" (i.e. inadequate) about having objects
defined entirely by their behavior in response to messages?
I think it would be best to focus on that last question first. I
believe a focus on that question would likely come to include
what for now I'm lumping into your "EQ" notion above.
Since I don't know what is wrong with objects being defined
entirely by their behavior I'm afraid I'll have to leave the initial
identifying of such failings to others such as Jonathan to establish
for the discussion. After the initial identification is made
perhaps I can get back into the discussion by trying to
find means to achieve the missing values with objects
defined by their behavior (network faithful).
More information about the cap-talk