From owner-freebsd-hackers  Sat Aug 10 23:25:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id XAA14508
          for hackers-outgoing; Sat, 10 Aug 1996 23:25:48 -0700 (PDT)
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA14495
          for <hackers@freebsd.org>; Sat, 10 Aug 1996 23:25:45 -0700 (PDT)
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id QAA18341; Sun, 11 Aug 1996 16:25:26 +1000
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
Message-Id: <199608110625.QAA18341@rf900.physics.usyd.edu.au>
Subject: Re: kern_mib.c:int securelevel = -1;
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 11 Aug 1996 16:25:26 +1000 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199608102005.GAA07178@godzilla.zeta.org.au> from "Bruce Evans" at Aug 11, 96 06:05:04 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
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.

The Xserver would be using the VGA 64k area in this case -- check the
startup output and see what it says.  This isn't an option for some
non-S3 chips.

>>``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.

It is for accessing the linear framebuffer.  That's why it is called
"aperture" driver.  Here is a short decription of it:

  This driver works like the standard /dev/mem driver. It just allows
  mapping of the VGA framebuffer even if kernel security level is > 0.
  The driver only implements the open(), close() and mmap() calls. In
  order not to defeat kernel security, only one open() at a time is
  allowed and only a process with effective user id of 0 can perform
  it. So while you're running XFree86, no other process will be allowed
  to open /dev/xf86.

I don't agree with the implication there that it doesn't allow kernel
security to be defeated though.

>>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

It should be easy to provide this for PCI cards, but perhaps not so easy
for VLB cards without chipset-specific code in the console driver.

David