Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!a.cs.uiuc.edu!p.cs.uiuc.edu!gillies From: gillies@p.cs.uiuc.edu Newsgroups: comp.arch Subject: Re: PEP: Page Execution Priviledge Message-ID: <76700049@p.cs.uiuc.edu> Date: 1 Oct 88 06:18:00 GMT References: <2550@sultra.UUCP> Lines: 37 Nf-ID: #R:sultra.UUCP:2550:p.cs.uiuc.edu:76700049:000:1900 Nf-From: p.cs.uiuc.edu!gillies Oct 1 01:18:00 1988 Well, your system isn't exactly like Multics, but it has some similarities. A central idea of Multics is that the rights of a program are determined by its addressing descriptors. The descriptors are basically capabilities for memory segments, and they contain rights bits. You have decided to append your rights bits to each fixed-size page; Multics appends its rights bits to each variable-size data segment capability. The Multics way has an advantage -- different programs may efficiently share the same segment, with different rights for each program. There are a few problems with your method, however. One problem: How do you prevent a user-call from transferring to some random non-instruction on one of these protected pages? In Multics, you could only jump to the beginning of a protected segment, I believe (ENTER). When are these bits validated? Are they kepts in some sort of cache and validated on every use? What happens when someone wants to "declassify" one of these segments? A fundamental advantage of the Multics design is that it's simple enough to implement in hardware, and yet it supports access-control list protection. A fundamental flaw of the Multics design is that ring zero is omnipotent, and domain trust must nest. There exist capability-based protection schemes (e.g. Plessey/250 System) with essentially NO omnipotent protection domains (except for the necessary one that manufactures capabilities), and no nesting of trust. Thus, I believe it is still an open problem to design a hardware scheme that simultaneously supports access-control-list protection efficiently, but does away with this omnipotent supervisor domain, and does not enforce the Multics nesting constraint. Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies