From owner-freebsd-hackers Sat Aug 10 23:51:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA16770 for hackers-outgoing; Sat, 10 Aug 1996 23:51:17 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA16760 for ; Sat, 10 Aug 1996 23:51:13 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29866 for ; Sun, 11 Aug 1996 08:51:12 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA21485 for freebsd-hackers@freebsd.org; Sun, 11 Aug 1996 08:51:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA04874 for freebsd-hackers@freebsd.org; Sun, 11 Aug 1996 08:50:11 +0200 (MET DST) From: J Wunsch Message-Id: <199608110650.IAA04874@uriah.heep.sax.de> Subject: Re: kern_mib.c:int securelevel = -1; To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 11 Aug 1996 08:50:10 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199608110035.RAA00338@rah.star-gate.com> from Amancio Hasty at "Aug 10, 96 05:35:21 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Amancio Hasty wrote: > > It's not so easy to provide since: > > > > 0) the graphics console drivers are too dumb to know about the details > > of their devices, so they have no idea where the frame buffer > > actually is. This is the usual ``the DDX layer should actually be > > in the kernel'' problem. > > > If all what you want to add is the frame buffer then it should be easy > to move the mapping of the frame buffer to the console drivers. > In essence move the logic to map the frame buffers from the hardware > specifics in the "DDX layer" to the kernel. Alas, this would require to move many chipset-specific hacks into the kernel, something that doesn't fit in the current model. It's really a question of whether moving DDX into the kernel or not. The mmap code in DDX is nothing less or more hardware-specific than, say the clocks programming. Btw., Bruce, if it doesn't refuse to work in securelevel > 0, our securelevel is broken. The code always tries to mmap() /dev/mem first, and opens a descriptor O_RDWR for this purpose. Only if this fails, it complains at stderr, and falls back to banked mode mapping /dev/ttyv0. NetBSD's aperture driver works with /dev/xf86, but i haven't looked how the mapping is validated and prevented from being abused to map an arbitrary piece of memory. Perhaps the driver restricts the mapping to the known VGA window or anything beyond the end of physical RAM, which is certainly not ideal but would at least prevent abusing it to spy the physical RAM. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)