Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!fstgds15.tu-graz.ac.at!fstgds01.tu-graz.ac.at!not-for-mail From: chmr@edvz.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.os.386bsd.bugs Subject: Re: Nethack Date: 4 Jul 1993 17:01:35 +0200 Organization: Technical University of Graz, Austria Lines: 85 Message-ID: <216rcfINNj4@fstgds01.tu-graz.ac.at> References: <21678c$13q@klaava.Helsinki.FI> NNTP-Posting-Host: fstgds01.tu-graz.ac.at X-Newsreader: TIN [version 1.1 PL7] In article <21678c$13q@klaava.Helsinki.FI> Linus Torvalds (torvalds@klaava.Helsinki.FI) wrote: -> In article <214al6INNsmp@fstgds01.tu-graz.ac.at> chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes: -> >In article <1993Jul3.055522.4000@fcom.cc.utah.edu> A Wizard of Earth C (terry@cs.weber.edu) wrote: -> >-> In article <C9J9H8.Ltu@sneaky.lonestar.org> gordon@sneaky.lonestar.org (Gordon Burditt) writes: -> >-> > -> >-> >Now, the question I have is, with this bug in the system, why does -> >-> >it stay up for more than 10 minutes? Why can I run the compiler -> >-> >without it crashing? -> >-> > -> >-> >Is there a 486-specific fix for this (set the WP bit in the cr0 register? -> >-> >anything else needed or is that alone enough?) -> >-> -> >-> This would probably be enough if the process creation code didn't depend -> >-> on it being unenforced during create. -> >-> -> >It is not enough with the current copyout: It basically uses the kernel -> >permissions to write to user space (same in copyin: You can read the kernel -> >memory with write() ). Also, if WP is on, you cannot map memory read-only -> >to the user and read-write for the kernel, but this is needed. -> -> Why? This seems like major braindamage, as I can't see any reasons for -> the kernel to write to WP'd user pages and not get a SIGSEGV. mmap() -> and friends should go through the page tables anyway, and should fill in -> the page with any startup data before even inserting it into the user -> VM, so why are they using "copyout" in the first place? Linux enables WP -> by default on a 486, and I don't think it needed any kernel changes at -> all. The current copyout is braindead; but that is simple to fix. The problem with the WP-bit is that the user area is currently mapped read-only, because the signal code requires this (I think -- correct me if I'm wrong), and the kernel stack is also in the user area... mmap is no problem here, and it does not use copyout. -> -> >The 'bug' of the VM system is that is assumes read-only memory cant be modified. -> >The *bug* of the copyout family is that it happily writes to read-only memory. -> >It is obvious what should be fixed. (I'm working on a clean+fast patch). -> -> For speed, could I suggest doing the WP checks only once, and not in -> copyout? I haven't looked at the 386bsd sources, but I assume that -> copyout is used for partial ranges of memory for things like "read()" -> that copies the data in chunks from the buffer cache. It's probably -> more efficient to check the whole memory-area given as parameters to -> read first (you'd have to do this to check for EFAULT anyway), and then -> not worry about it at all in copyout(). Otherwise you'll end up going -> through tha page tables several times (for every byte if you are unlucky -> with terminal reads or something). Hmmm. copyout is used by far more than read alone (ioctl, some device drivers etc), did you include the check in all these places ? The check in copyout isn't that expensive, on 486 (with the WP bit) and in copyin it's basically setting a segment register and the rest is done by the hardware. EFAULT is also returned by the copyout family (the new ones, forget the old hack). And yes, for terminal reads we'll probably check the PTE for each byte (on 386 or without the 486 WP bit). But terminal reads are normally not important for performance (who can type fastest ? 8-), and I think someone is working on changing terminal reads to use copyout instead of subyte. -> -> And for your own sanity, may I suggest cleaning up the kernel so that WP -> can be enabled: anything which breaks WP right now is probably a kernel -> bug, really. I can't imagine that the original BSD sources depended on -> the bad 386 behaviour: that wouldn't be portable. Enabling WP also gets -> rid of the checks totally in a 486 (as well as being a good debugging -> tool: it can be used to check the behaviour of the 386 routines, as the -> WP errors should never trigger if they work all right). Bruce Evans does this (correct ?). The original BSD sources depend on URKW (user-read, kernel-write) protections. It's a design flaw of the 386 that is does not support URKR, but the 'fix' on the 486 that adds URKR and disables URKW is half-baked, too. There are still enough 'reserved for future extensions' bits in the Page Table Entry. All smart processor implementations have separate protection bits for user and kernel mode. -> -> Linus I really like the way you post to the 386bsd groups, concise technical articles without any sort of bitching on your 'concurrence' product. Too bad that is not always possible even within the *BSD groups. Christoph