[rfc] VIA dri and security.

Thomas Hellström unichrome at shipmail.org
Sun Oct 10 14:48:33 PDT 2004


Hi!

Sorry for the double posting. This is a thing that needs to be discussed 
in both communities.

The via DRM has started it's journey into the linus kernel, but the 3D 
driver / DDX still suffers
from a security flaw:

When the MMIO area is exported read-write it is assumed possible for a 
dri client to manipulate registers to
blit otherwise protected areas of the system memory to video memory. It 
is the DDX that tells the DRM whether to export the MMIO area read-only 
or read-write. The OpenGL 3D driver unichrome_dri.so currently needs 
write access to this area, until someone fixes it up to use register 
writing ioctls now present in the via drm.

The obvious fix is for the DDX to tell DRM to export the MMIO area as 
read-only. In this way a normal user would get a segfault when trying to 
run accelerated OpenGL, while it would work as root.

There's been a discussion at the unichrome site, where most of the via 
DDX development is taking place at the moment, on whether to leave the 
user with this only option. We propose a solution where the user could 
use a driver option "AllowInsecureDRI" to have the MMIO area exported 
read-write. The security hazards of doing this is briefly explained in 
the via man-page and warning message will be output in the X server log 
if this option is enabled.

Since we also plan on syncing the development with the via driver in 
Xorg it's important that this does not violate any security policy in 
Xorg. We figure that to open up the system in this way, you still need 
to be root and the option name speeks for itself. Also the average user 
would more likely damage his system running a 3D application as root 
than be the subject of somebody exploiting this vulnerability.

The current via DDX in Xorg allows read-write access to these registers.

It would be good to have some comments / ideas about whether the 
proposed solution could be considered OK.

Regards
Thomas







More information about the xorg mailing list