Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!seismo!lll-lcc!mordor!sri-spam!sri-unix!hplabs!decwrl!decvax!tektronix!uw-beaver!ubc-vision!van-bc!sl From: sl@van-bc.UUCP Newsgroups: comp.os.minix Subject: Re: MINIX memory management/protection Message-ID: <352@van-bc.UUCP> Date: Sat, 7-Feb-87 15:18:51 EST Article-I.D.: van-bc.352 Posted: Sat Feb 7 15:18:51 1987 Date-Received: Tue, 10-Feb-87 02:23:55 EST References: <252@hqda-ai.UUCP> <1169@steinmetz.steinmetz.UUCP> <511@bobkat.UUCP> <888@cartan.Berkeley.EDU> Reply-To: sl@van-bc.UUCP (Stuart Lynne) Organization: Public Access Network, Vancouver, BC. Lines: 90 Keywords: shared swapped jobs Summary: RTFM! It works! In article <888@cartan.Berkeley.EDU> ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) writes: >In article <511@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) writes: >>In article <1169@steinmetz.steinmetz.UUCP> davidsen@kbsvax.UUCP (william E Davidsen) writes: >>> >>>If you allocate a full 64k to data, there is hardware protection: you >>>can't address more than that. This assures that any program which >>>doesn't deliberately set out to cause problems will not modify the >>>code. ... >> >>What about a program with a bug in it? Like "strcpy(a, b)" when "a" is >>not quite what I meant? It's real easy to make this kind of mistake; >>how many times while debugging a program on a VAX (or whatever) do you >>get SIGBUS or SIGSEGV? >[Omitted here: a description of a phenomenon with which I'm sure we are > all too painfully familiar -- how wild pointers can crash programs and > machines.] > > I think you have missed a key point here which depends on the iAPX86 >architecture. Because addresses are constructed as SEGMENT:OFFSET, as long >as the compiler generates no code that would reload the segment registers >and as long as you do not use any assembly code in your program that does >this, then you are physically constrained to 64K bytes starting at absolute >location 16 * SEGMENT. Since pointers are passed only as offsets, the >worst you can do is scribble over your 64K segment. > > However, this is a blatant lie, and it is possible you are >vindicated. For, if auto variables are allocated on the stack, one >could still easily lose. Since the stack must lie in the same segment >as the static data (otherwise, pointers must have segments associated >with them to distinguish between auto and static variables), it is >possible to scribble over the stack. In doing so, one could alter a >return address and find oneself in another process, or perhaps the >kernel. Also, equally likely is that one would try to execute data >and encounter an illegal opcode. I believe (but I am not certain) >that this halts the 8086. > > So, in summary, it turns out you are right, in an indirect >sort of way. >-------- NO! RTFM! This is a very safe way to keep programs from clobbering the system. To quote from the Intel iAPX 88 Book: "For an intrasegment CALL, SP (the stack pointer) is decremented by two and IP is pushed onto the stack. The target procedure's relative displacement (up to +- 32k) from the CALL instruction is then added to the instruction pointer. This CALL instruction form is "self-relative" and appropriate for position-independant (dynamically relocatable) routines in which the CALL and its target are move together in the same segment. "For an intersegment direct CALL, SP is decremented by two, and CS is pushed onto the stack. CS is replaced by the segment word contained in the instruction..... "... RET pops the word at the top of the stack (pointed to by register SP) into the instruction pointer and increments SP by two. If RET is intersegment, the word at the new top of stack is popped into the CS register....... If properly done the compiler never emits code to modify ANY of the four segment registers. This includes the code segment register. Calls, and returns have two versions, inter and intra segment. You simply have to restrict yourselft to only using intrasegment calls, returns, jumps, loads and NOTHING your program does will go outside of your 64k segments. This includes such things as clobbering the stack as you described. The only possible way is to have self-modifying code :-). Again, simply restrict you emitted code to not modifying anything relative to the CS register, and ensure that when you load the program with the 64k code segment not overlapping the 64k data segment. This has been used for years with such systems as Coherent which is a Mark Williams Version 7 Unix look alike. I used it for about a year and can't remember ever having it blow up because of a runaway program (while doing software development). -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532 Todays feature: Perry Mason Solves the Case of the Buried Clock, Erle Stanley Gardner, 1943. A bank clerk boasted branzenly about a $90,000 embezzlement, and an alarm clock ticked away cheerfully underground.