Re: [RFC] enhancing the kernel's graphics subsystem

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/21/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > the kernel, it can be a lot smaller than X and auditable.. sticking
> > > the DRI protocol in the kernel is just pointless..
> >
> > It is a quite sensible idea.
> >
> > The userspace X server SHOULD be running under a non-root user, with
> > appropriate fine-grained privs granted to it.
> >
> > "I need root to do graphics" is a myopic, antiquated view of the world.
>
> X server: priviledges below everything, pageable
> kernel: priviledges as high as conceivable, non-pageable
>
> So why do you want it in kernel.... security is not the sensible answer
> here.

Have you inspected the multi-megabyte X server for security holes to
the same level the kernel has been inspected?

The only part that needs to be in the kernel driver is the code
controlling locking and code that plays with the hardware. Moving it
into the driver ensures that only the minimal amount of root priv code
possible is going to end up in the system. If someone tries to move
too much into the kernel I'm sure you'll let them know that it's a bad
idea.

The problem right now is that code that needs root priv is all
intertwined with code that doesn't need it and it all ends up getting
run as root.

BTW, when I prototyped this a couple of years ago by merging Radeon
DRM/fbdev I only needed to add about 10K more code to the device
driver. Most of that was associated with getting the VBIOS to run in
x86 mode when the driver was first loaded. That code can be marked
_init. We're not talking about a lot of code needing to go into the
kernel.

--
Jon Smirl
jonsmirl@gmail.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/