From owner-freebsd-hackers  Sat Dec 30 22:05:45 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA09527
          for hackers-outgoing; Sat, 30 Dec 1995 22:05:45 -0800 (PST)
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA09522
          for <hackers@freebsd.org>; Sat, 30 Dec 1995 22:05:38 -0800 (PST)
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id RAA16875; Sun, 31 Dec 1995 17:05:13 +1100
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
Message-Id: <199512310605.RAA16875@rf900.physics.usyd.edu.au>
Subject: Re: /dev/io
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 31 Dec 1995 17:05:13 +1100 (EST)
Cc: smpatel@wam.umd.edu, hackers@freebsd.org, jkh@time.cdrom.com
In-Reply-To: <199512310546.QAA19107@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 04:46:29 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
Precedence: bulk

>>> For what it's worth, the XFree86 servers get I/O permission by using
>>> the KDENABIO ioctl in the console driver rather than by opening /dev/io.
>
>>I wasn't even aware that this existed, but looking at the Xserver source
>>it seems like BSDI, Linux, FreeBSD, and NetBSD all have it (but only
>>Free/NetBSD use it for Xserver IO permission). 
>
>I wasn't aware that /dev/io existed for a long time :-).
>
>>This makes it even easier to phase out /dev/io, because the Xservers will
>>not break and the code for iopl() would be very similar to the code for
>>the KDENABIO ioctl.
>
>I prefer to have this security hole in only one device.  I/O permission
>should not be allowed when securelevel >= 2.  One way of implementing
>this is to remove all of the other holes and classify /dev/io as a kmem
>device and change its interface so that a write() is required to get
>I/O permission.  (iskmem() really means that writing to the device is a
>security hole.)
>
>>The only non-trivial thing would be implementing IO
>>permission bitmaps, but I'm not even sure if it's worth it since it would
>>be a rarely used feature. 
>
>I think they are only worth it if you want to use securelevel >= 2
>and things like X.

Another thing X needs is to mmap the video memory (which is usually done
by mmapping /dev/mem).  That can't be done at securelevel >= 2 can it?
For NetBSD there is an "aperture" driver to deal with this.  It does
weaken security when the driver is not in use (it is single open).
A better way would be to have a /dev/fb.  Automatic configuration of
something like that wouldn't be too bad for most PCI video cards, but for
others it will make X server configuration even more difficult than it
is now (but perhaps that's tolerable if you need to run at a high
security level).

David