Date: Sun, 31 Dec 1995 16:46:29 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199512310546.QAA19107@godzilla.zeta.org.au>
To: dawes@rf900.physics.usyd.edu.au, smpatel@wam.umd.edu
Subject: Re: /dev/io
Cc: hackers@freebsd.org, jkh@time.cdrom.com
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.

Bruce