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