Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!cartan!brahms.Berkeley.EDU!ballou From: ballou@brahms.Berkeley.EDU.UUCP Newsgroups: comp.os.minix Subject: Re: MINIX memory management/protection Message-ID: <912@cartan.Berkeley.EDU> Date: Mon, 9-Feb-87 03:44:52 EST Article-I.D.: cartan.912 Posted: Mon Feb 9 03:44:52 1987 Date-Received: Tue, 10-Feb-87 03:36:00 EST References: <252@hqda-ai.UUCP> <1169@steinmetz.steinmetz.UUCP> <511@bobkat.UUCP> <888@cartan.Berkeley.EDU> <352@van-bc.UUCP> Sender: news@cartan.Berkeley.EDU Reply-To: ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) Organization: Math Dept. UC Berkeley Lines: 42 Keywords: shared swapped jobs In article <352@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In article <888@cartan.Berkeley.EDU> ballou@brahms.Berkeley.EDU (Kenneth R. Ballou) writes: [Omitted here: various discussions about whether there is hardware protection from clobbering the system with a runaway program.] >NO! RTFM! This is a very safe way to keep programs from clobbering the >system. I propose to demonstrate that your claim of safety is false. Consider carefully the following possible scenario. 1. Since stack and data are in the same segment (this is forced upon you once you decide that pointers are represented by 16 bit offsets into a segment, since you must be able to take addresses of both static and auto variables), it is possible that with a wild pointer you could overwrite the stack frame associated with the current procedure call. In particular, you could alter the return address for your procedure. Now, you are correct in asserting that since the return address is a 16 bit offset, you will return to some location in your code segment. 2. However, no guarantee is made that the address to which you return will be the address of one of the instructions in your code. Consider in particular that the byte at the location to which you return is FF hex. If you RTFM, you will note that this is a far JMP instruction. The effect of this is that the next two bytes will be stuffed into the IP register, and the two bytes thereafter will go into the CS register. At this point, you are officially in for disaster. You might either end up in another process's code segment, in a data segment (in which case, watch the CPU hang because of an illegal instruction which is eventually going to occur from trying to execute data), or in some unallocated region of memory. In any case, you have lost big. I believe Don Kneller also pointed out less disastrous losses; you might find yourself executing code which reloads a segment register. In any case, there are enough things that could go wrong that the idea of this scheme being safe is incorrect. SUMMARY: Simply using a small memory model is not enough to guarantee safety of your process. -------- Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720