From owner-freebsd-hackers  Sat Dec 30 22:55:21 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id WAA10992
          for hackers-outgoing; Sat, 30 Dec 1995 22:55:21 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA10969
          for <hackers@freebsd.org>; Sat, 30 Dec 1995 22:54:32 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA21313; Sun, 31 Dec 1995 17:50:52 +1100
Date: Sun, 31 Dec 1995 17:50:52 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199512310650.RAA21313@godzilla.zeta.org.au>
To: bde@zeta.org.au, dawes@rf900.physics.usyd.edu.au
Subject: Re: /dev/io
Cc: hackers@freebsd.org, jkh@time.cdrom.com, smpatel@wam.umd.edu
Sender: owner-hackers@freebsd.org
Precedence: bulk

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

Mmapping /dev/vga only requires root permissions.  Does X still uses
this?  It used to be good enough before there were linear frame buffers.

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

The X server would have to feed back the frame buffer addresses to the
driver.  This would have to be done soon after boot time or before boot
time.  This wouldn't be too hard if there aren't many addresses.

There are likely to be more problems with magic i/o's.  Consider a
graphics board that can do DMA or otherwise access system RAM (are there
any such supported by XFree86?).  To stop the X server doing this (after
it has been subverted) i/o's would have to be restricted to certain
ports.  The X server could securely feed back the list of ports that it
wants to the driver, much like it does for frame buffer addresses.
However, the list would be much longer, and if the same ports are used
for both security holes and normal operations. then a simple list
wouldn't be good enough.

Bruce