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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/21/07, Alan Cox <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux