Date: Sun, 27 Apr 1997 12:42:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@freebsd.org Subject: Re: sysctl -A Message-ID: <199704271942.MAA09077@phaeton.artisoft.com> In-Reply-To: <19970427091019.YV06768@uriah.heep.sax.de> from "J Wunsch" at Apr 27, 97 09:10:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704271942.MAA09077>