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,da46977c58c329df X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-08 07:53:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!uio.no!193.216.69.35.MISMATCH!dax.net!juliett.dax.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Ada's Slide To Oblivion ... References: <4519e058.0201310714.650888e1@posting.google.com> <3C598CAA.7040801@home.com> <3C59FCD3.928144FB@adaworks.com> <7v8za79id0.fsf@vlinux.voxelvision.no> <3C6288CB.3227AF20@cfmu.eurocontrol.be> <3C62D397.8040001@mail.com> <%rC88.3860$oC3.2148048@typhoon.san.rr.com> <3C63AB8A.F52337D8@cfmu.eurocontrol.be> <7vlme4w4ax.fsf@vlinux.voxelvision.no> <3C63CB16.645FE25E@cfmu.eurocontrol.be> From: Ole-Hjalmar Kristensen Message-ID: <7vheosvums.fsf@vlinux.voxelvision.no> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Feb 2002 15:52:42 GMT NNTP-Posting-Host: 193.216.12.150 X-Complaints-To: abuse@tele2.no X-Trace: juliett.dax.net 1013183562 193.216.12.150 (Fri, 08 Feb 2002 16:52:42 MET) NNTP-Posting-Date: Fri, 08 Feb 2002 16:52:42 MET Organization: Tele2 Norway AS Public Access Xref: archiver1.google.com comp.lang.ada:19778 Date: 2002-02-08T15:52:42+00:00 List-Id: Ian Wild writes: > Ole-Hjalmar Kristensen wrote: > > > > ??? This is pure fantasy. How do you think the code got into the code > > space in the first place? > > (sigh) > > Let's take the example of a 68000 'cos I've got the data sheet > readily available. There are three lines coming out of the > processor which distinguish various spaces. Of interest are: > > supervisor code > supervisor data > user code > user data > > If the OS is clever, and many of them were, it's set up the MMU > tables such that 'user code' exists at some point in 'supervisor > data', at least long enough to load the executable from disc. At > some later point it may re-map things so that 'user data' exists > at that same address in 'supervisor data', letting it initialise > the bss. At some late stage it initialises the MMU so that > 'user code' starts at address 0, 'user data' starts at address 0 > (but with the first page unmapped to catch NULL pointers), and > does a mode switch. There is then NO WAY from user mode to write > to the 'user code' space, and only limited (ie PC relative) access > for reading. > > Oh - before anyone suggest it, no, the MMU is not visible from > user mode either. > > Is this really rocket science? I would've though the above > sufficiently obvious that I could have got a patent on it. What you are saying now is correct, but that's not what you said in your previous post. Of course these processors have mecahnisms which can be used to protect code from being overwritten, but that's very different your statement that: >There > are wires that come out of the processor to say which space to use. On > such a system there's NO WAY to write to code space, ********