Graphics Driver Frameworks and Security

[Glynn Clements]

Alan Cox wrote:

> > X is responsible for making unreasonable demands of the OS (requiring
> > direct hardware access including the "right" to DMA over kernel
> > memory). The OS is responsible for acceding to those demands.
> 
> I think you need to look at the X code not random peoples rants. X.org
> does not require direct access to hardware, that's just the way some of
> the drivers have been written.  Its really up to the driver author and
> the kernel folks how they decide to implement it and the X.org tree
> contains examples of both methods.

	$ nm -D /usr/bin/X | fgrep ' U iop'
	         U ioperm
	         U iopl

	$ nm /usr/lib/modules/drivers/*.o | fgrep ' U iop'

	[nothing]

It isn't as if direct hardware access is something which a rogue
module is doing behind the X server's back.

But then my argument is that the problem isn't that the X server
(whether the main executable or a dynamically-loaded driver) uses
iopl(), but that the kernel provides it.

More so for OpenBSD, as they claim that:

	Our aspiration is to be NUMBER ONE in the industry for
	security (if we are not already there).

[http://www.openbsd.org/security.html]

Well, if X works (with a driver other than fbdev), they probably
aren't already there.

-- 
Glynn Clements <glynn at gclements.plus.com>