Subject: xsrc/21986: Kernel API needed for finding/configuring GPU
To: None <>
From: Erik E. Fair <>
List: netbsd-bugs
Date: 06/25/2003 00:54:46
>Number:         21986
>Category:       xsrc
>Synopsis:       Kernel API needed for finding/configuring GPU
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 25 07:56:00 UTC 2003
>Originator:     Erik E. Fair
>Release:        NetBSD 1.6
The NetBSD Project
	NetBSD's primary Xserver is from XFree86. XFree86 does some
	very ugly things to find the graphics processing unit(s)
	(GPUs) in systems - it scans the PCI/AGP space from user mode.
	It should not have to do this, because:

	1. this has a serious impact on system integrity (user mode
	processes should not, in general, be allowed to poke
	individual devices directly like that without kernel
	mediation, let alone an entire I/O address space),

	2. it hinders portability; we already have a lovely API
	for accessing chips in a bus-independent manner, which is
	required by the very large number of busses we support
	(e.g. PCI, NuBus, Sbus, TURBOChannel, Unibus, MASSbus,
	Qbus, etc.). XFree86 should be able to concentrate (for
	now) on GPU drivers in a more bus-independent manner.

	The NetBSD kernel generally already knows what XFree86 is
	attempting to find out (everything is probed at boot time
	by autoconfiguration); we simply lack an API to tell
	XFree86's Xserver what it wants to know. We should define
	such an API, implement it, and both send the changes back
	to the XFree86 project, and suggest its adoption by the
	other *BSD Projects and Linux.

	While this will not solve the security issues involved in
	having a user mode process poking a device that can, in
	principle, DMA anywhere in RAM it is programmed to, it is
	a step in the right direction. With enough step-wise
	refinement, we may eventually be able to re-secure the
	NetBSD system when X11 is in use.

	It should also result in one more manual configuration item
	being pulled out of the XFree86Config file, which would remove
	a class of user support issues.