The Linux Graphics Driver Stack Remains Insecure

The Linux graphics driver stack remains currently insecure with some fundamental issues that jeopardize the Linux desktop's integrity, but improvements are still being made to address the current issues.

Martin Peres and Timothée Ravier ignited the Linux graphics security discussion this morning in Brussels during FOSDEM. Their talk, which was entitled "DRI-next/DRM2: A walk through the Linux Graphics stack and its security", went over the current issues and some of what's being tried to improve the situation. The idea ultimately comes down to exposing a secure API to user-land and restricting GPU's RAM access rights.

The insecurity of Linux graphics isn't new but has been talked about previously in past years and what's been the driving forces behind DRI-Next and DRM2. The key goals being worked towards with these Linux graphics security improvements are to fight potential eavesdropping, tampering, and denial of service attack vectors that are possible with the current Linux graphics drivers and stack.

DRM2 / Render Nodes attempts to take care of DRM authentication policy and improve buffer sharing. The Direct Rendering Manager improvements would also allow using GPGPU/OpenCL applications without running an X.Org Server and other benefits. DRI-Next is about improving X.Org Server communication to fix shortcomings of DRI2 and DMA-BUF instead of GEM to share buffers.

What's still left TODO for DRM2 is to fix the DRM buffer object mmap-ing address from per-device to per-FDs, reworking the patches, including support for more graphics driver, testing every combination to check for no regressions, and porting DRM2 to Wayland/Weston. With DRI-Next, there's still research being done about using UNIX sockets for FD passing.

Right now in the Linux graphics driver world there's safeguards being used by different drivers to prevent other processes from reading/writing to memory that isn't their own. The ideal way is isolating users in a separate VM by restricting a GPU user to its own data through abstracting the memory address space. This method is already used by the Nouveau driver for NVIDIA GeFore 8 hardware and newer while it's possible to be supported by the AMD Radeon HD 7000 series and newer along with Intel Sandy Bridge graphics and newer.

The problem with this separate VM approach though is that it does increase the context-switching delay, which could particularly cause problems when using DRI2 and Qt5 and other cases. Right now what the Radeon and Intel open-source drivers is command submission validation by making sure they aren't accessing bad areas of RAM. This method yields a lower context-switching delay and doesn't have any specific hardwae requirements, but does come at a cost of higher CPU usage with needing to check the CS packets for their validity.

Among the ultimate goals expressed by Martin and Timothée are making it possible to implement activities and provide security between them, allow the end-user to decide what they want (e.g. if they want per-application isolation or prefer better performance), and to prepare the stack for GPGPU shared clusters and soon-to-come WebGL applications with better graphics driver security.

In their FOSDEM 2013 summary, they say the current state of affairs is that there's no confidentiality or integration between applications run by the same user, the current Linux graphics stack makes it possible to spy on users, there's no input security with X11 (but there is with Wayland/Weston), and that DRM2/DRI-Next should be good for stepping up the Linux graphics security.