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-09 11:32:05 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!145.254.32.125!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS Date: Sun, 09 Sep 2001 18:35:06 GMT Message-ID: <3b9b8162.641537@news.cis.dfn.de> 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> <3B9ACEB6.7F06DF1D@san.rr.com> NNTP-Posting-Host: 145.254.32.125 X-Trace: fu-berlin.de 1000060324 7839573 145.254.32.125 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:12953 Date: 2001-09-09T18:35:06+00:00 List-Id: On Sun, 09 Sep 2001 02:06:50 GMT, Darren New wrote: >> 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.) Yes, I must go through the kernel. >> 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.) No queues and no scheduling. >> 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. :-) That guy claimed that it is possible, efficient and _made_. Maybe he meant some special hardware, or? >> >> 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. In general same as with rendezvous and protected objects. Ada Rationale explains it excelently. >> >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". :-) To me process is mainly a subject of scheduling, like a task [maybe a set of tasks]. I would like to have something less-weighted and data oriented [vs. procedural processes]. Something that I would call *safe* object, sort of DLL, but more secure. >> 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. To me "read capability" is just a right to call the method "Read". It should work so that each method and data member have a guard. A caller/user should "bribe" that guard (:-)). So the set of capabilities is potentially unlimited. >> >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, Would be nice, but to be realistic I see no way other than a trap based implementation. >or you need to have the compiler >generate code that enforces this and prevent users from disabling that >code in any way. No, that would be a MS-DOS with an Ada compiler. >> 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. IMO Any attempt to dictate user what he/she should use, would deem the system. They would surely like to have a Java VM, Visual Basic and who knows what else. Let them, but ensure that nothing they write in Basic may crash the system if they run that crap with normal privilegies. >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". Absolutely. A process should have several "views" on its memory space. And a view change should go through the kernel. Regards, Dmitry Kazakov