From owner-freebsd-hackers  Sun Dec 31 00:24:52 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id AAA13122
          for hackers-outgoing; Sun, 31 Dec 1995 00:24:52 -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 AAA13116
          for <hackers@freebsd.org>; Sun, 31 Dec 1995 00:24:40 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA23798; Sun, 31 Dec 1995 19:19:11 +1100
Date: Sun, 31 Dec 1995 19:19:11 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199512310819.TAA23798@godzilla.zeta.org.au>
To: bde@zeta.org.au, dawes@rf900.physics.usyd.edu.au
Subject: Re: /dev/io
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>I think the key point is in how the X server securely feeds back the
>list of ports and fb addresses.  It would have to be done before entering
>multiuser mode -- either built in to the kernel (or handled with
>/kernel -c), or by running the X server with a special flag during boot.

This reminded me of lkms - you could have the addresses and possibly
some kernel X support in X_mod.o - but I think lkms shouldn't be
used if the kernel is going to be used at a high security level -
they would increase the number of weak points.

>If this can be done OK, then I don't think there would be problems with
>the same ports being used for both security holes and normal operations
>providing the /dev/fb device is single-open (to prevent spying on the
>fb contents).  Making it single-open prevents the running of multiple
>servers, or use of the new DGA extension, but I think that's inevitable
>at a high security level.

The mapped ports can be determined by accessing them and seeing if a
signal is generated (unless the kernel traps these accesses specially).
Anyway, port like 3D4/3D5 are likely ;-) to be mapped and they only
need one insecure index register in them to cause problems.

I think these problems are best handled by not allowing the X server to
be restarted (is that what you meant by "prevents running of multiple
servers").  Start the X server and let it grab I/O permissions and
memory maps the same as now before entering secure mode, and don't allow
these operations at all in secure mode.  This reduces that problem to
the usual one of protecting the server's text and data after it has
started.

Bruce