Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ihnp4!chinet!steinmetz!davidsen
From: davidsen@steinmetz.UUCP
Newsgroups: comp.os.minix
Subject: Re: Memory handling in MINIX ?
Message-ID: <1167@steinmetz.steinmetz.UUCP>
Date: Fri, 30-Jan-87 11:43:24 EST
Article-I.D.: steinmet.1167
Posted: Fri Jan 30 11:43:24 1987
Date-Received: Sat, 31-Jan-87 23:36:00 EST
References: <5490004@nucsrl.UUCP>
Reply-To: davidsen@kbsvax.UUCP (william E Davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 41

In article <5490004@nucsrl.UUCP> naim@nucsrl.UUCP (Naim Abdullah) writes:
>Does anybody know whether /dev/mem and/or /dev/kmem exist in MINIX ?
>
>I seem to recall a discussion in the then net.unix-wizards about
>a year ago on running UNIX on an ibm pc. The consensus seemed to be
>that multi tasking was hard because there is no memory protection
>hardware. A process could presumably overwrite the kernel. How did
>Andy solve this problem ? Is a MMU a standard part of a pc ? These
>questions may be naive but I know very little about the pc hardware.

The 8086 family does not have a general purpose memory manager, but it
does have segmentation. A process running small model has up to 64k
code, 64k data, and 64k stack. Because pointers will index in the data
segment, most implementations put the data and stack in the same 64k.

In any case, while no one claims that this is enough protection in a
*hostile* environment, it is perfectly adequate for general
multitasking. Because the data and code segments don't overlap, there
is no way to overwrite code (by accident). If a program avoids
modifying the segment registers themselves, only the 64k data and stack
segments can be modified. That *is* hardware protected.

The only way a program on a PC can overwrite the kernal (or any other
program) is to hand generate the code to modify the segment registers.
The instruction code are not used in any legitimate program, and are
not generated by languages such as C.

Having done software development on PC/IX for several years, I feel
fairly confident in saying that you will never have a problem unless
you deliberately cause one. I would be willing to let users run
applications on such a machine without qualms. If the environment were
"hostile", where the users had access to a compiler or assembler, and
where thay might try to damage the system deliberately, the 8086 family
does not provide adequate protection. The 80286 and 80386 have
protected modes which are based both on memory mapping and on privilege
levels (kernal, executive, normal, and debug).
-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@crd.ge.com (or davidsen@crd.ge.com)