Patches Arrive For DRM2 Render Nodes Support
Taking a brief break from his direct work on Wayland, Kristian Høgsberg has published his "Render Nodes" work for DRM2 following the recent DRM2 proposal.
There was a DRM2 proposal at XDC2012 earlier this month to increase the Direct Rendering Manager security.
Kristian explains in his mailing list patch series:
A while back there was also other render node work being done by David Airlie.
There was a DRM2 proposal at XDC2012 earlier this month to increase the Direct Rendering Manager security.
Kristian explains in his mailing list patch series:
The core problem is that DRM security is compromised in the face of VT switching and multiple DRM masters. Any local user can access all shared buffers from within any X server on the system, even when that user doesn't have access to any of those X servers.The DRM render nodes patches amount to just a few dozen lines of code across three patches. With the current patches from Kristian, render nodes support is only implemented in the Intel DRM and not within Radeon, Nouveau, or other drivers.
The fix for this is to use dmabuf/prime and fd passing for buffer sharing. That infrastructure is already in place and we need to start using that in user space. Once we're passing buffers between display servers and clients in a point-to-point fashion, we no longer need to authenticate clients. We just need to make sure they can only render and import/export buffers to fds. That's what this patch does, by creating a new type of drm device node. Accessing this node doesn't require authentication (and as such can be used without a master, ie headless), but will only expose the safe, modern (DRI2ish) rendering ioctls.
Once userspace is sharing buffers through fd passing, the legacy card0 node can be locked down by unix permissions, for example in a drm-master group, so that only setgid binaries (X, weston, other KMS apps) can access it.
A while back there was also other render node work being done by David Airlie.
Add A Comment