1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

The Linux Graphics Driver Stack Remains Insecure

X.Org

Published on 02 February 2013 11:56 AM EST
Written by Michael Larabel in X.Org
10 Comments

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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  2. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  3. KVM Benchmarks On Ubuntu 14.10
  4. X.Org Server 1.16 Officially Released With Terrific Features
Latest Linux News
  1. GStreamer VA-API Plug-In Update Adds New Features
  2. Qt 5.4 Going Into Feature Freeze Next Week With Exciting Changes
  3. OpenSUSE Factory Turns Into Rolling Release Distribution
  4. "The World's Most Highly-Assured OS" Kernel Open-Sourced
  5. NVIDIA Is Working Towards VDPAU H.265/HEVC Support
  6. Hawaii Bug-Fixes Start Hitting Mainline RadeonSI Gallium3D
  7. The FFmpeg vs. Libav War Continues In Debian Land
  8. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  9. GCC As A Just-In Time Compiler Is An Interesting Project
  10. Age Of Wonders III Is Still Being Ported To Linux
Latest Forum Discussions
  1. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  2. AMD Athlon 5350 APU On Linux
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Debian + radeonsi
  5. Open-source drivers on ATI R7 260X
  6. List of Linux friendly Kickstarter projects
  7. Porting Mesa to the Playstation 2
  8. ASRock AM1H-ITX: One Of The Best AM1 Mini-ITX Motherboards