Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Dec 1995 17:05:13 +1100 (EST)
From:      David Dawes <dawes@rf900.physics.usyd.edu.au>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        smpatel@wam.umd.edu, hackers@freebsd.org, jkh@time.cdrom.com
Subject:   Re: /dev/io
Message-ID:  <199512310605.RAA16875@rf900.physics.usyd.edu.au>
In-Reply-To: <199512310546.QAA19107@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 04:46:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310605.RAA16875>