From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-08 19:06:55 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!newsfeed1.cidera.com!Cidera!cyclone.tampabay.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3B9ACEB6.7F06DF1D@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS References: <3b95d429.592218@news.cis.dfn.de> <3B9654AE.CD4382ED@san.rr.com> <3b9768b6.1671036@news.cis.dfn.de> <3B97A5C7.3ED71528@san.rr.com> <3b9876e0.334859@news.cis.dfn.de> <3B98EEA2.179DD2A1@san.rr.com> <3b99f79e.751695@news.cis.dfn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 09 Sep 2001 02:06:50 GMT NNTP-Posting-Host: 24.165.20.126 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 1000001210 24.165.20.126 (Sat, 08 Sep 2001 19:06:50 PDT) NNTP-Posting-Date: Sat, 08 Sep 2001 19:06:50 PDT Xref: archiver1.google.com comp.lang.ada:12934 Date: 2001-09-09T02:06:50+00:00 List-Id: > >> If there is "a process that supplies a service", then it is another > >> process, i.e. the method is executed on another context. > > > >I'm not sure how you would enforce any sort of access control in the > >case of only having one context, actually. > > Well there should be several contexts of one process. Then you can use capabilities between those contexts with low overhead. > For instance, > let an application owns a "safe" object. It is safe in the sense that > its data cannot be accessed otherwise than through the object's > methods. OK. That means that to get to this object, you need to trap into the kernel to change the memory protection. (Or you need more sophisticated hardware, sure.) > To enforce this the corresponding memory pages should be > normally inacessible for [read/]write. However when an object's method > is called, there should be a context switch upon the call that would > make the memory pages accessible for read/write. Upon return the > context is switched back. I'm not sure how this is more efficient than two separate processes, if your hardware requires you to do context switches to change the memory mapping. It's two separate contexts in one process, but it's only incidental that it's one process. (Actually, it's kind of pushing the limitations of the definition of "process" I think.) > I very like the idea, someone mentioned in a parallel thread, that the > access rights can be made dependant on the page the PC points to. Yeah. As an aside, I thought of doing this under CP/M about 20 years ago. Never got around to it, tho. :-) > >> This is > >> another case and a heavy weighted one. It would be very inefficient to > >> have a separate process for every object. > > > >It doesn't need to be a separate process for every object. Indeed, in > >Ameoba (Tannenbaum's OS), all the files are managed by one process. > > It is no matter one or many. It is like the difference between > rendezvous and protected objects. You simply need both of them because > rendezvous are inherently slow when compared with protected objects > and yet not all necessary things can be made using solely protected > objects. If you're trapping to the kernel to change memory protection in order to do your call, I'm not sure what the efficiency benefits are between doing that in one "process" or in two, especially if the two processes can share memory to pass parameters and such. > >You don't have a capability for each array or tagged object, for > >example, because you're not trying to protect them from yourself. > > Yes, but there are exceptions. Consider an object OpenKeyPair given to > an application. The application is allowed to use its public methods > (Code/Sign/Encode), but it cannot read its data, create a copy of it > or pass it to another application. Then you need to put it in a different process, if your definition of "process" is "all the code that can get to the same memory areas". If that's not your definition, then you need to define clearly what you mean by a "process". :-) > I have nothing against capacities if they allow to have access rights > to object's methods and members dependent on the access level to the > object itself. [Of course only "safe" objects are considered.] Yes, of course they do. Many capabilities can be served by the same object. A file could have a read capability, a write capability, and a delete capability. If you look at the file server as the "object", then all the files on that file server are access to different methods and data members. > >I think if you have the protected object in your data space, there's not > >much point in enforcing an administrative limitation on who can get to > >it. On the other hand, if your hardware supports capabilities directly, > >then there's no problem with doing this. > > IMO it is very important to have *safe* objects living in the process > space, because then a lot of things could be made within the process > time quant, which otherwise would be served by some driver, ACP etc, > with a catastrophic impact on real-time issues. Then you need to enforce it differently. You either need very sophisticated access control hardware, or you need to have the compiler generate code that enforces this and prevent users from disabling that code in any way. > Agree. It is how it could be implemented in a machine of usual > achitecture. Maybe sometimes CPUs will support type tags, then... [at > least 15 years old idea] (:-)) Or use the Hermes/NIL ideology, and let users only use high-level languages that enforce pointer checking, array bounds checking, and etc. But if you use capabilities as part of your IPC, you don't really need to do this. I think no matter how you slice it, you're not going to be able to put "safe" objects in a process if the user's allowed to use assembler and you define "process" as "accessible memory space plus one or more threads". -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. Those who work hard with few results always value hard work over getting results.