Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!orion.oac.uci.edu!uci-ics!gateway From: baxter@zola.ICS.UCI.EDU (Ira Baxter) Newsgroups: comp.arch Subject: Re: Capabilities and Object Oriented Programming Message-ID: <9004091928.aa26181@PARIS.ICS.UCI.EDU> Date: 10 Apr 90 02:29:58 GMT Lines: 120 In-reply-to: Your message of Mon, 09 Apr 90 14:41:53 -0100. <9004091401.aa06032@PARIS.ICS.UCI.EDU> Just to provide some fresh air, I am posting a copy of this reponse to comp.arch. There's way too much RISC vs. CISC discussion there :-{. >> Do you have any suggestions/references on the use of capabilities >> by operating systems, and particularly distributed operating systems. >> In particular, I am interested in understanding how capabilities >> are used in these systems, and if hardware support is appropriate >> (how have capabilities been implemented on conventional hardware, >> what approach has been taken so far to provide hardware support, and >> what have been the problems and benefits of such support). >> Well, I am more interested in capabilities than I am an expert on it. Having said that, now I will proceed to stick my foot in my mouth. The major (real!) architectures I know about consist of the IBM Sward architecture (which I think evolved into the IBM System 38 aka AS440(?) ), the CMU Hydra (W. Wulf et al) operating system for C.MMP (16 PDP-11s with a giant crossbar switch), and the CAP computer system (Needham et al, U. of Cambridge). I am afraid that I do not have easily found references on these (I am packing, and those references got packed first) but those pointers should at least get you close. There is also a Digital Press book on Capability-Based Operating Systems which seemed interesting (but it, too, is packed, sigh). Last, but not least, there was an OS called Octopus that Lawrence Livermore Laboratories fooled around with some on their heterogeneous computer network; but I don't know where that work ended up. [I'll bet some soul on the network has a pretty complete bibliography on capability systems; care to post it?] >> It seems to me that to effectively/efficiently implement a capability >> based operating system, which most distributed systems are turning into, >> (or object-oriented language as well) there is going to need to be some >> form of hardware support. All of the experience in the past with >> capability based hardware (Intel's iAPX432, and the 80960XA that BiiN >> used) was in supporting a secure, Ada type environment which has never >> become very popular. I have heard of BiiN, but don't know anything about it. It isn't clear to me that these architectures died of "Ada-type environment"; I would guess rather that they died of dog-slow performance, and their failure to match the marketing requirements of running DOS or Unix :-{{{{{{ Perhaps we have to wait for *next* internet worm to make serious protection schemes marketable. I think it is just a matter of time. >> The most valuable experience would be in supporting >> one of the popular and current systems like Mach, V, Amoeba, etc., and >> seeing what benefits you get out of the architecture. It is papers >> discussing capabilities in these contexts, especially relating to >> implementation issues that I am interested in. 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. The usual trick for conventional architectures implementing capabilities is to use map hardware to partition process space into code, data, and capability segments. The capability segment isn't really manipulable by the user process; rather the process uses integer indices to reference the capabilities. In this way, the user processes have no idea of the physical content of capabilities, nor can it diddle them. Object handlers exist for capabilities and remind one very much of all the OOP stuff now going on. The issues seem to be how to create new capabilities, how to delete priveleges from capabilities when handing them on, how to "amplify" priveleges in the object handlers (the Hydra stuff is heavily into this), and how to handle dangling capabilities (those for objects which have disappeared). A topic little discussed is the inconvenience of the capability segment; it is hard to pass capabilities around, (you have to pass the integer index instead), and one has to somehow allocate the slots in the capability segment (fixed allocation? garbage collection?). This is why I like the Amoeba encrypted capability idea (if it is indeed what I think it is, I have not seen any literature on it yet). One can treat a capability just as any other data object; this would work well on a conventional RISC/CISC machine. The loser is that to execute an operation on an object, one would have decrypt the capability; here is where architectural support would be a big win. Consider a machine that had index registers for pointing to objects. Loading a capability into an index register could decrypt it on the spot (like the Intel 386 segment registers appear to do.). If we insist that operations on the object be done *only* through index registers (if you think of objects as memory, this looks amazingly like RISC!), then one can dynamically check the operations as they fly by. Instructions to restrict the capabilities represented by an index register would be cheap because the capability can be stored internally in a decrypted form. Storing the index register re-encrypts it. >> >> Also, it seems to me that there is confusion around capabilities as >> an object in the operating system, and capabilities as a feature of the >> architecture (a capability for a file being the former, and a capability >> for an memory buffer being the latter). There might (probably should) be >> some relation between the two; some clarification/exploration of the >> differences and similarities of these two ideas would also be interesting >> to hear about. I saw an article that someone posted describing the >> difference as being between an I/O multiplexor and an IPC multiplexor... >> do you know anywhere where this differentiation is explored/explained. No. But I can't see it should be different than software support for floating point vs hardware implementation of the same; it is really a matter of performance (with some protection issues thrown in). The interesting issue here is, how can one design something like IEEE fp standard for capabilities, so that they can be used on dissimilar "architectures" in a standardized way? >> Brad Smith >> PS - Any luck on the KeyKOS references? Not yet. But I'm not pursuing it very hard.