From owner-freebsd-hackers Sat Aug 10 13:06:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17528 for hackers-outgoing; Sat, 10 Aug 1996 13:06:43 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA17521 for ; Sat, 10 Aug 1996 13:06:37 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA07178; Sun, 11 Aug 1996 06:05:04 +1000 Date: Sun, 11 Aug 1996 06:05:04 +1000 From: Bruce Evans Message-Id: <199608102005.GAA07178@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de Subject: Re: kern_mib.c:int securelevel = -1; Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Have you tried it? :-) X works fine even at securelevel 2. >I haven't tried it, but i think at doesn't work if you've got a I tried an S3-868. >graphics device where the Xserver wants to access the linear >framebuffer via /dev/mem. At least, i remember vaguely the term That certainly won't work. >``NetBSD aperture driver'' and the stated reason that this was >intended to be a backdoor in order to circumvent the /dev/mem >problem. I thought it was to circumvent the /dev/io problem. >Plain (banked) VGA probably works, since it only needs to mmap() the >standard frame buffer where syscons or pcvt do already know about its >location. This mapping should be provided by the driver in all cases. It's much easier to provide than safe access to i/o ports for the following reasons: 0) Access to the frame buffer is always safe. 1) FreeBSD doesn't support restricted access to i/o ports. 2) i/o is slower when CPL > IOPL. 3) It isn't clear which ports can be accessed safely. Standard graphics ports can probably be used to blow up old monitors. 4) I/O ports sometimes need to be programmed in groups while interrupts (especially context switches) are disabled. This requires an insecure IOPL. Bruce