On Fri, Sep 28, 2012 at 12:35 PM, Kristian Høgsberg <krh@xxxxxxxxxxxxx> wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > 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 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. > I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Alex > Kristian > > > See also: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security > > https://lwn.net/Articles/517375/ > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel