Date: Sun, 31 Dec 1995 18:17:33 +1100 (EST) From: David Dawes <dawes@rf900.physics.usyd.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: Re: /dev/io Message-ID: <199512310717.SAA17039@rf900.physics.usyd.edu.au> In-Reply-To: <199512310650.RAA21313@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 05:50:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310717.SAA17039>