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 Articles & Reviews
  1. OS X 10.10 vs. Ubuntu 15.04 vs. Fedora 21 Tests: Linux Sweeps The Board
  2. The New Place Where Linux Code Is Constantly Being Benchmarked
  3. 18-GPU NVIDIA/AMD Linux Comparison Of BioShock: Infinite
  4. Phoronix Test Suite 5.6 Adds New Phoromatic Enterprise Benchmarking Features
  5. OpenGL Threaded Optimizations Responsible For NVIDIA's Faster Performance?
  6. Big Graphics Card Comparison Of Metro Redux Games On Linux
Latest Linux News
  1. Git 2.4.0-rc0 Does A Ton Of Polishing
  2. The Most Common, Annoying Issue When Benchmarking Ubuntu On Many Systems
  3. Mesa Is At Nearly 1,500 Commits This Year
  4. Gestures & Other GTK3 Features For LibreOffice
  5. It's Now Easier To Try PHP 7 On Fedora & RHEL
  6. BQ Is Cleaning Up Their Aquaris E4.5 Ubuntu Kernel
  7. Allwinner Continues Jerking Around The Open-Source Community
  8. NVIDIA Linux 349.12 Beta Has Improved G-SYNC & VDPAU Features
  9. Canonical Just Made It Even Easier To Benchmark Ubuntu Linux In The Cloud
  10. NVIDIA GeForce GTX TITAN X Linux Testing Time
Most Viewed News This Week
  1. Introducing The Library Operating System For Linux
  2. AMD Is Hiring Two More Open-Source Linux GPU Driver Developers
  3. New SecureBoot Concerns Arise With Windows 10
  4. GNOME Shell & Mutter 3.16.0 Released
  5. GNU Nano 2.4.0 Brings Complete Undo System, Linter Support & More
  6. Systemd Change Allows For Stateless Systems With Tmpfs
  7. GCC 5 Compiler Is Getting Close To Being Released
  8. Chromebooks Powered By The MIPS Pistachio, Linux Support Evolving