On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote: > Hi, > > Following to my shared talk with krh, danvet and Timothée Ravier @ > XDC2012, I have > actually taken the time to start fixing some security holes found in > the graphics stack. > > Today, I would like to request your comments on the render node > patchset. Keep in mind that I am > not asking for inclusion. However, I know this patchset works on my > nvidia card and I would like > to know if anyone has anything against this architecture. > > ## DRM > If I'm not mistaken, the idea originated from airlied which got > simplified later by krh. > Both only provided drm patches. > > Here is what I did: > - I took krh's patchset > - rebased it on top on drm 3.7-rc8 > - added support for Nouveau > - fixed a few bugs along the way (as stated in the commit logs) > > The kernel can be found here: https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes > The patches will also be sent in reply, to let you comment on > specific parts of the patches. One thing which stalled this on the kernel side, and I think we really need this before it's useful, is per-open-file mmap spaces. Otherwise everyone can still read back your textures easily ... I've looked around a bit, and besides the plumbing to set up per-open-file mmap offset infrastructure it shouldn't be hard, the linux mm already passes in the file pointer to the ->mmap driver callback. One thing though is to clean up things a bit maybe - iirc ttm based drivers use their own lookup cache for mmap offset, and there's still the legacy drm map support which really shouldn't be exposed to rendernodes. I have this on my todo somewhere, but at the current rate&backlog it'll take a while for me to get around to this, so maybe I can volunteer you? Also I think we need this implemented just in case some aweful userspace breaks due to the per-file mmap space (there's been some decently aweful code in intel-land ...). I can't really comment on the other pieces of this due to lack of knowledge. Cheers, Daniel > > ## Libdrm > > Here are the two main goals of this patchset: > - Add a new symbol called drmOpenType that allows to open a specific > type of device (usual node, render node) > - Add a new symbol called drmGetSameDeviceButType to get the path to > the same drm_device but with a different type > > The patches are available here: http://cgit.freedesktop.org/~mperes/drm/ > > ## DRI2Proto > > What we want here is to let the ddx send the render node instead of > the usual one. > However, authentication is not necessary and not shouldn't be done > on a render node. > > This modification to DRI2Proto adds a boolean in the Connection > response to tell the dri2 client > that no authentication is required. > > The patches are available here: > http://cgit.freedesktop.org/~mperes/dri2proto/ > > ## XServer > > The X-Server is responsible for collecting the DRI2 informations > from the ddx. > In this patch, we provide the way for the ddx to specify whether the > DRI2 client should authenticate or not. > > The patches are available here: http://cgit.freedesktop.org/~mperes/xserver/ > > ## xf86-video-nouveau > > In this patch, we simply tell the DRI2 extension to use the render node if > available (using drmGetSameDeviceButType), and if it is the case, > we set the "require_authentication" attribute to 0. > > The patches are available here: > http://cgit.freedesktop.org/~mperes/xf86-video-nouveau/ > > ## Mesa > > In this patch, I simply check whether I should authenticate or not > using the information > from the DRI2 protocol. > > The patches are available here: http://cgit.freedesktop.org/~mperes/mesa/ > > Cheers, > > Martin > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
