From owner-freebsd-hackers Sat Dec 30 23:17:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA11597 for hackers-outgoing; Sat, 30 Dec 1995 23:17:53 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA11592 for ; Sat, 30 Dec 1995 23:17:46 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id SAA17039; Sun, 31 Dec 1995 18:17:33 +1100 From: David Dawes Message-Id: <199512310717.SAA17039@rf900.physics.usyd.edu.au> Subject: Re: /dev/io To: bde@zeta.org.au (Bruce Evans) Date: Sun, 31 Dec 1995 18:17:33 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199512310650.RAA21313@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 05:50:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text 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. It is only used if /dev/mem can't be mmapped and if the requested address is in the range /dev/vga can handle. It isn't good enough for cards which require the use of a linear fb. >>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 XFree86 doesn't support any graphics boards that do DMA. >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. 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. 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. David