Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!patrick
From: patrick@convex.com (Patrick F. McGehearty)
Newsgroups: comp.arch
Subject: Re: Capabilities and Object Oriented Programming
Message-ID: <101335@convex.convex.com>
Date: 10 Apr 90 15:14:44 GMT
References: <9004091928.aa26181@PARIS.ICS.UCI.EDU>
Sender: usenet@convex.com
Organization: Convex Computer Corporation; Richardson, TX
Lines: 51

In article <9004091928.aa26181@PARIS.ICS.UCI.EDU> baxter@zola.ICS.UCI.EDU (Ira Baxter) writes:
>
>I found the CMU Hydra system to be one of the most interesting,
>because they built capabilities on top of conventional hardware
>(mostly by using trusted OS kernal routines); I think there were
>a pretty good series of articles on it in SIGOPS sometime in late 70s,
>early 80s.

Some references:
Proceedings of the Fifth Symposium on Operating System Principles,
19-21 November, 1975 at Univ. of Texas at Austin

"Overview of the Hydra Operating System Development" by W. Wulf, R. Levin,
and C. Pierson.

"Policy/Mechanism Separation in Hydra" by R. Levin, E. Cohen, W. Corwin,
F. Pollack, and W. Wulf.

"Protection in the Hydra Operating System" by E. Cohen and D. Jefferson.
-----
The CAP system appears in the
Proceedings of the Sixth Symposium on Operating System Principles,
 16-18 November, 1977 at Purdue Univerisity

"The Cambridge CAP Computer and its Protection System" by R.M. Needham and
R.D.H. Walker.

"The CAP Filing System", by R.M. Needham, and A.D. Birrell.

"The CAP Project - An Interim Evaluation", by R.M. Needham
------
Other Proceedings on the various Operating System Principles are likely to
have worthwhile papers also, but I don't have immediate access to them.

I worked on measurement of the Hydra system, so I speak from experience when
I say that the implementation overhead of handling capabilities makes a
critical difference in how useful they are.  Hydra had a relatively high
overhead in entering the kernel due to the extensive checking that was
required to maintain domain boundaries, since little direct hardware support
was available for this purpose.  Thus, any capability based operation was
quite expensive.  In the original design, the interprocess communication
system was implemented outside the kerenl.  The overheads were so large as
to make the system virtually unusable.  Because of the expected need for
frequent communication in a multiprocessor environment, this system was
moved into the kernel.  If capability access had been cheap, this change
would not have been necessary.

I have my doubts about encrypted capabilities for performance reasons.  If
encryption is fast, then code cracking is feasible, which breaks the
protection.  If encryption is not fast, then capabilities will be bypassed
to avoid the overheads, again breaking the protection.