naim@nucsrl.UUCP (01/23/87)
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.
Naim
{ihnp4, chinet}!nucsrl!naimmerlin@hqda-ai.UUCP (01/25/87)
In article <5490004@nucsrl.UUCP>, naim@nucsrl.UUCP (Naim Abdullah) writes: > Does anybody know whether /dev/mem and/or /dev/kmem exist in MINIX ? Yes, they exist. /dev/mem reads physical memory starting at address 0, where the interrupt vectors are located. /dev/kmem reads physical memory, also. However, to simulate "kernel virtual space", /dev/kmem begins reading at address 0x600 (1536 decimal). That's where MINIX loads. Other than the 1536-byte offset, the two are identical. > 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 ? He didn't, really. A process is allocated as much text space as it needs, and (normally) 64k for data and stack space. [Well-behaved programs can be allocated less.] There is a "gentlemen's agreement" that no one writes anywhere but in their data segment, which is referenced by the DS or SS segment registers. The C compiler abides by this. However, someone writing in assembler *could* overwrite anything they chose. > Is a MMU a standard part of a pc ? No. One of the major failings of the PC architecture. On the AT (80286), there is some help here, but not much. The Compaq Deskpro 386 (80386) does have the requisite hardware as part of the '386 processor chip. -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 ARPA: merlin%hqda-ai.uucp@brl-smoke UUCP: ...!seismo!sundc!hqda-ai!merlin
dan@prairie.UUCP (01/25/87)
In article <254@hqda-ai.UUCP> merlin@hqda-ai.UUCP (David S. Hayes) writes: >In article <5490004@nucsrl.UUCP>, naim@nucsrl.UUCP (Naim Abdullah) writes: >> Is a MMU a standard part of a pc ? > > No. One of the major failings of the PC architecture. On >the AT (80286), there is some help here, but not much. What does "some help here" mean? The 286 has virtual, relocatable segments, memory protection, protection rings, segment permissions, separate global and local segment spaces, and call gates. All the 386 adds is paging of the underlying linear address space. Admittedly, that's a big "all", but the substantial stuff is all in the 286. All the real Unices for the AT provide virtual memory a la the pre-paging Vax implementations. -- Dan Frank ARPA: dan@db.wisc.edu ATT: (608) 255-0002 (home) UUCP: ... uwvax!prairie!dan (608) 262-4196 (office) SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006
radford@calgary.UUCP (01/27/87)
In article <254@hqda-ai.UUCP>, merlin@hqda-ai.UUCP (David S. Hayes) writes: > ... There is a > "gentlemen's agreement" that no one writes anywhere but in their > data segment, which is referenced by the DS or SS segment > registers. The C compiler abides by this. However, someone > writing in assembler *could* overwrite anything they chose. Are procedure return addresses stored in this data space? If so, a C program can still crash the machine by altering a return address, returning to some random piece of code, and writting all over everything. Does anyone know how difficult it would be to make MINIX totally secure against crashes by programs written only in C? Radford Neal
rlk@chinet.UUCP (01/29/87)
In article <5490004@nucsrl.UUCP> naim@nucsrl.UUCP (Naim Abdullah) writes: >Does anybody know whether /dev/mem and/or /dev/kmem exist in MINIX ? > ... quoted from p. 142 of the book (which arrived yesterday, so I haven't looked at much of it yet and can't comment on its completeness or robustness). "... The code for handling /dev/ram, /dev/mem, and /dev/kmem is identical. The only difference between them is ..." -- --- UUCP: ..!ihnp4!chinet!uklpl!rlk || MCIMail: rklappal || Compuserve: 74106,1021 ..!ihnp4!ihu1h!rlk ---
mark@ems.UUCP (01/30/87)
I doubt that there is any way to assure that a C program will not currupt the memory and bring the macine down in Minix yet. The 'gentlemens' agreement is the only memory check that is ensured by the 8086 hardware. It is possible to bring MS-DOS down in a big hurry with a 'misbehaved' C program, and it looks like Minix is a little more delicate, albeit a lot more powerful, than MS-DOS. I doubt the segment checking will get put into place until a port is done to a chip that supports it, such as the 80286, 80386, 68000. Supposedly the 68000 port is underway, but I do not know if they will support segmentation checks or not.
davidsen@steinmetz.UUCP (01/30/87)
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)
henry@utzoo.UUCP (Henry Spencer) (02/01/87)
> > Is a MMU a standard part of a pc ? > > No. One of the major failings of the PC architecture... Wrong, the PC has an MMU, just not a particularly good one. The box does not have to have protection, demand paging support, etc. etc., to be called an MMU. The PC's MMU does relocation only. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (02/01/87)
> Does anyone know how difficult it would be to make MINIX totally > secure against crashes by programs written only in C? Barring gross modifications to the compiler and a major loss of efficiency in the generated code, it's impossible given 8088 or 8086 hardware. For Pascal it could be done, but C lets you do too many dirty things like pointer arithmetic. To do it properly you'd need an MMU which supports protection as well as relocation, i.e. a 286 or 386. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ji@garfield.columbia.edu (John Ioannidis) (02/02/87)
In article <7599@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> > Is a MMU a standard part of a pc ? >> No. One of the major failings of the PC architecture... >Wrong, the PC has an MMU, just not a particularly good one. The box does >not have to have protection, demand paging support, etc. etc., to be called >an MMU. The PC's MMU does relocation only. Where did you guys get the idea that the PC has an MMU? Ever opened a hardware reference manual? .EXE programs are patched at load time by the EXEC call so that they can be loaded anywhere in memory. There is no hardware support for it. Reading the manuals helps, you know... #include <appropriate_disclaimers> VOICE: +1 212 280 5510 ARPA: ioannidis@cs.columbia.EDU USnail: John Ioannidis ji@garfield.columbia.EDU 450 Computer Science Columbia University, USENET: ...{seismo|topaz}! New York, NY 10027 columbia!garfield!ji ... It's all Greek to me!
alexande@drivax.UUCP (02/10/87)
In article <4292@columbia.UUCP> ji@garfield.columbia.edu.UUCP (John Ioannidis) writes: >.EXE programs are patched at load time by the EXEC call so that they can >be loaded anywhere in memory. There is no hardware support for it. Yes, but .COM programs are not patched. They run anywhere you load them (if written properly). As the DOS Technical Reference says about program loading: For .COM programs: all four segment registers contain the segment address of the initial allocation block... Thus the segment registers can be thought of as a very cheap MMU. This sort of scheme can be used on MINIX, but wouldn't allow shared code (because code == data == stack == heap). >Reading the manuals helps, you know... Sure does! -- Mark Alexander ...{hplabs,ucbvax!decvax}!decwrl!pyramid!amdahl!drivax!alexande "This then is my story. I have reread it. It has bits of marrow sticking to it, and blood, and beautiful bright-green flies." --Nabokov
henry@utzoo.UUCP (Henry Spencer) (02/21/87)
> Where did you guys get the idea that the PC has an MMU? Ever opened a hardware > reference manual? Yes, the one for the 8088, which is the chip inside the PC. They call it "segment registers", but it's there. (Once I had read the manual, I put it away on a dark back shelf in hopes I would never have to see it again. So far so good...) > .EXE programs are patched at load time by the EXEC call so that they can > be loaded anywhere in memory. There is no hardware support for it. So the software is the pits, what else did you expect on a micro? -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry