[RFC] Complete experimental render node implementation

[Daniel Vetter]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch