Graphics Driver Frameworks and Security

[Dave Airlie]

> For those who haven't seen it yet, there is a nice new flame by Theo de
> Raadt:
>
>    http://marc.theaimsgroup.com/?l=openbsd-misc&m=114738577123893
>
> While I don't like Theo's tone and assigning blame etc., on the actual
> issue I couldn't agree more.
>
> There are a lot more reasons why the KGI approach makes a lot of sense,
> but IMHO the security issue is a very convincing one by itself...

As a favour to me in this thread can people please restrict themselves
to only giving out about the fact that X causes OS'es to expose
/dev/mem and give access to ioports (using iopl) and in general allows
root to do things, even if the OS is designed to stop root doing them,
(i.e. BSD securelevels or SELinux type protections)..

I just know people will start talking about setuid, direct rendering
interfaces, privledge separation and all the other security issues
that X has, which are all fixable without putting a pile of code in
the kernels,

The problem is the OS'es expose MMIO registers to userspace read/write
so that the root user can access them, this means that any process
running as root can program the DMA engines that most modern cards
have, and use that to disable OS-level protections such as BSD
securelevels or SElinux, you don't need SMM, you don't need access to
a /dev/mem (read write to PCI /sys resource files will work, if you
can read/write the DMA engine registers).

Dave.

Dave.