Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Dec 1995 16:46:29 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        dawes@rf900.physics.usyd.edu.au, smpatel@wam.umd.edu
Cc:        hackers@freebsd.org, jkh@time.cdrom.com
Subject:   Re: /dev/io
Message-ID:  <199512310546.QAA19107@godzilla.zeta.org.au>

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

Bruce



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