Messages in this thread | | | Date | Mon, 21 May 2007 20:45:09 -0400 | From | "Jon Smirl" <> | Subject | Re: [RFC] enhancing the kernel's graphics subsystem |
| |
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/
| |