Graphics Driver Frameworks and Security

[Alan Cox]

On Maw, 2006-05-16 at 04:28 +0200, olafBuddenhagen at gmx.net wrote:
> While I don't like Theo's tone and assigning blame etc., on the actual
> issue I couldn't agree more.

Take a look at his argument in detail

He claims:
1. "X server *REQUIRES* access to the raw hardware"

Well actually it doesn't. Whether you bitbang hardware, use a kernel
provided interface for the card or just some kind of mediated hardware
interface (eg one that allows only the relevant ports to be accessed) is
entirely a matter for the driver. In the Linux case you will find all of
the variants

2. "This is called the "device drivers in userland" model.  It violates
all the security models you will hear of in a university class."

Also not really true. In fact a lot of microkernel work is exactly in
that direction and is aimed directly at improving reliability and
security. 

Another way to think about this:

Let us suppose that X has a security hole in some component. If that
component is driver level then putting the hole into the kernel instead
reduces security (as it is now even more privileged). If the hole is in
a component that is not driver level then it is better fixed by making
that part of the code unprivileged.

In other words it is a question of compartmentalisation and address
space isolation NOT of drivers in user space.

3. "what Microsoft did solved all these driver security problems!"

Not exactly backed up by the evidence, in fact the Microsoft stuff
rather shoots down his argument. There is an X.org based X server for
Windows. Guess what it does, it calls Microsofts in kernel video, the
thing he is claiming X can't do 8)

4. "This problem is ENTIRELY the X group's fault!  They have failed us."

I'm not aware of X.org ever having been paid large amounts of money by
the OpenBSD developers to provide such a product, perhaps someone on the
board would know about that 8)


That all said, if you want to provide a kernel side interface to the X
server then the existing XAA and EXA APIs should be entirely sufficient.
A driver that uses either XAA or EXA and fires them at a kernel driver
is not hard to write. You would want to provide an mmap of some of the
frame buffer space as well but that can be done safely.

Performance might be a concern but again you can batch all the write
commands up until a read back or a flush (and XAA will ensure that
occurs when it should).

That would be an interesting and useful project that can be done within
the existing framework, and indeed *IS* done this way by at least vmware
although it is driving a virtual card that is in fact their hypervisor.

Generally speaking the X.org code really doesn't care whether you bash
the hardware or call the kernel in your driver. It's designed well
enough that it *doesn't need to*.

Alan