Graphics Driver Frameworks and Security

[olafBuddenhagen at gmx.net]

Hi,

On Tue, May 16, 2006 at 11:45:08AM +0100, Alan Cox wrote:

> 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

Right. But existing solutions like fbdev solve only part of the problem,
and are generally too limited to be a real alternative to the mainstream
userspace drivers in X. That's precisely the reason why we need a proper
KGI to make avoiding direct hardware access feasible.

> 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. 

Well, I'm a supporter of the microkernel approach myself; so if you want
to go in that direction, I can only applaud. But then you need to be
serious about it, add all the necessary infrastructure for doing such
stuff in userspace properly, refactor dependant components etc., i.e.
effectively create a proper microkernel system.

Attempting to make exceptions for a specific component in an otherwise
monolithical system by half-arsed adhoc "solutions", *inevitably*
results in a mess like the one we see with graphics drivers today.

Any argument for userspace graphics drivers is really an argument for
proper microkernel designs, not for inconsequent design exceptions.

However, with Linus recently reinforcing his position on microkernels
(and also hybrid solutions), we can be pretty certain that for the time
being any graphics driver solution has to be considered primarily in the
context of monolitic systems.

> 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.

I agree. I indeed do consider the clear seperation of hardware access
from higher level driver functionality offered by KGI more fundamental
than the fact that it runs in the kernel; and my personal major interest
in KGI actually is porting it to a microkernel system, where it will run
as a userspace process. (Which makes the name KGI really inappropriate,
but well...)

However, such systems are *designed* to do things like that in
userspace, from ground up. Monolithic systems are not. In monolithic
systems, the kernel is the designated and obvious place to put the
hardware access part, and trying to do differently is just calling for
problems. It's the (monolithic) kernel's damn responsibility to ensure
secure hardware access with robust multiplexing.

Also, with the console system, the kernel itself is a user of graphics
hardware access. So -- unless you are willing to move half of the kernel
functionality into userspace as well -- the kernel is the *only* place
where the hardware access can reside, if we want to avoid the current
mess with several different drivers in various places controlling the
same hardware.

> 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.

Sure, it is possible to create EXA modules that will call into the
kernel by some individual interfaces. But I don't think indvidual
interfaces for every driver is really what we want.

Also, EXA AFAIK only handles drawing, not all the really problematic
stuff with hardware detection/setup etc., so it would be only a partial
solution. Of course you could add all kinds of kernel hooks in various
places of the X server (on top of those that are already in place); but
this will only make the driver mess even worse than it is now, instead
of cleaning it up.

What we really need is a single well-designed generic kernel interface
for graphics hardware access, and a userspace component for talking to
it. This userspace component can and should be a generic library
independant of the X server, so the server can just call into it not
bothering about the actual driver backend. This way it can also run both
on KGI or on various traditional interfaces.

Note that the GGI project ( http://www.ggi-project.org ) does provide
somewhat rudimentary but working implementations of all this. The
existing KGI backend is in a pretty bad state now, but the userspace
component (libggi) runs pretty well on other backends. (fbdev/directfb
is probably the most useful backend for running the X server as long as
we lack a working KGI.)

XGGI ( http://www.ggi-project.org/xggi/ ) is a variant of the xorg
server that calls into libggi instead of the traditional DDX. It misses
various extensions, but otherwise works.

-antrik-