From owner-freebsd-hackers Sun Apr 27 12:47:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA25502 for hackers-outgoing; Sun, 27 Apr 1997 12:47:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA25497 for ; Sun, 27 Apr 1997 12:47:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09077; Sun, 27 Apr 1997 12:42:18 -0700 From: Terry Lambert Message-Id: <199704271942.MAA09077@phaeton.artisoft.com> Subject: Re: sysctl -A To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 27 Apr 1997 12:42:18 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <19970427091019.YV06768@uriah.heep.sax.de> from "J Wunsch" at Apr 27, 97 09:10:19 am X-Mailer: ELM [version 2.4 PL24] 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 > > My DEC Alpha runs at secure level 1, and X works fine. > > So now, look and tell us how they're doing it. They map the display memory with a kernel call. > I know how XFree86 avoids the problem on NetBSD, with the NetBSD > aperture driver. But i also know that this is only another kind of a > hack, and it's arguable whether you are still allowed to call it > `securelevel 1' with the aperture driver. It's easy to find a race to > break the security model. I don't think this is necessaary. It may be specific to the machine architecture as some people have suggested, so maybe not a good general soloution in any case. An aside: NetBSD also prevents the loading of LKM's in secure mode, so they are arguably more "overboard" about it than the FreeBSD folks, anyway. > Pulling all the dix code from the Xserver into the kernel would be the > technically correct solution, but is out of the question due to the > sheer amount of work required (and due to decentralizing the > maintenance that's currently done in an operating-system independent > way by the XFree86 team). Well, don't dismiss it so trivially before you try it. If the device dependent drivers were shared objects, I don't think they would care who was loading them and calling them: XFree86 or the kernel. If that's the case, then if you can freeze an interface, you should be able to use the same code in both places, and still have the maintenance where it is today. The one hiccup you will face is importing the interface over the kernel boundry into the X server; this will take a small amount of work in the X server to have to address the kernel interface instead of loading the shared object for the driver and addressing the shared object directly. It *should* be possible to provide a shared object that looks like a device dependent driver on the top end... so it's one more (small) driver that would need to be written to support the DDX in the kernel case on any given OS (or once, if the interface were generalized enough that the Linux and similar folks could live with it). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.