*BSD News Article 17917


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!swrinde!cs.utexas.edu!uunet!emba-news.uvm.edu!trantor.emba.uvm.edu!wollman
From: wollman@trantor.emba.uvm.edu (Garrett Wollman)
Subject: i386 memory protection bugs
Message-ID: <1993Jul3.212610.18043@uvm.edu>
Sender: news@uvm.edu
Supersedes: <1993Jul3.212502.17988@uvm.edu>
Organization: University of Vermont, EMBA Computer Facility
References: <1993Jul3.055522.4000@fcom.cc.utah.edu> <214al6INNsmp@fstgds01.tu-graz.ac.at>
Date: Sat, 3 Jul 1993 21:26:10 GMT
Lines: 62


In article <214al6INNsmp@fstgds01.tu-graz.ac.at> chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes:

>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.

I was perusing the Mach 3.0 MK68 (?) sources the other day, and I
noticed how they handle this:

Pages which are not supposed to be writable for the kernel are left
unmapped!  Here's the code in question from kernel_trap(), in
kernel/i386/trap.c:

                /*
                 * Since the 386 ignores write protection in
                 * kernel mode, always try for write permission
                 * first.  If that fails and the fault was a
                 * read fault, retry with read permission.
                 */
                result = vm_fault(map,
                                  trunc_page((vm_offset_t)subcode),
                                  VM_PROT_READ|VM_PROT_WRITE,
                                  FALSE,
                                  FALSE,
                                  (void (*)()) 0);
#ifdef	MACH_KDB
	/* code omitted for brevity */
#endif  MACH_KDB
                if ((code & T_PF_WRITE) == 0 &&
                    result == KERN_PROTECTION_FAILURE)
                {
                    /*
                     *  Must expand vm_fault by hand,
                     *  so that we can ask for read-only access
                     *  but enter a (kernel)writable mapping.
                     */
                    result = intel_read_fault(map,
                                          trunc_page((vm_offset_t)subcode));
                }

		}

The code also uses a rather nice trap-recovery mechanism, which seems
much more elegant (and thread-safe!) than the current pcb_onfault
mechanism.  It also includes the hardware-assist code used by the DOS
(really BIOS) emulator.

-GAWollman

-- 
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant

-- 
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman      | It is a bond more powerful than absence.  We like people
UVM disagrees.       | who like Shashish.  - Claude McKenzie + Florent Vollant