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-10 10:21:50 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!b87d3.pppool.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS Date: Mon, 10 Sep 2001 17:24:56 GMT Message-ID: <3b9cb179.1274575@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> <3b9b8162.641537@news.cis.dfn.de> <3B9BD2A8.2B2090D5@san.rr.com> NNTP-Posting-Host: b87d3.pppool.de (213.7.135.211) X-Trace: fu-berlin.de 1000142507 8091885 213.7.135.211 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:12994 Date: 2001-09-10T17:24:56+00:00 List-Id: On Sun, 09 Sep 2001 20:35:57 GMT, Darren New wrote: >> >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]. > >Usually, the difference between a "process" and a "task" is that a >process doesn't share memory with any other process. A "task" shares >memory with all the other tasks in the same process. Yes, I said "like a task" because of this difference. A process is a safe task. >However, now you've >moved away from the standard terminology, so saying "it's really the >same process, but with different memory access" means you need to define >precisely what you're talking about. :-) I many OSes a process may have several tasks [threads]. Why not to have several memory mappings as well? >> 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. > >OK. Then what you're looking for can be done with capabilities, *if* you >have hardware to support them directly (like OO hardware might) or if >you want to have the kernel remapping memory permissions. Yes. >> 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. > >Correct. That's why you need it at some user level, rather than >kernel-enforced. Why not? Could a capacity be represented by a tagged type, and so that dispatch [sometimes] happens on the kernel context? Of course if an object is declared on the user level there is little sense to check its capacities on a more secure level. But there will be system objects too. >> >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. > >Err, sorry? No, you'd have a Burroughs B-series. They worked it by >having privledged (think "setuid" type priveledge) programs which were >the only ones allowed to write "executable" code, and those programs >were responsible for making sure you didn't do the Wrong Thing. > >> >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. > >Yes. And you can do this by either using hardware protection, or using a >VB interpreter that doesn't let them run off the end of arrays. The >JavaVM (other than JNI etc) certainly doesn't need hardware support to >keep you from doing something nasty - that's the whole idea of the >sandbox. What about hardware/software faults? I do not very believe in pure software protection. In any case the protection should be deeply echeloned. Regards, Dmitry Kazakov