Le 18/12/2012 13:03, Daniel Vetter a écrit :
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 ...
Yeah, krh told me about it. It was on this week's todo list but it may be pushed back to this week end.
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?
Sure! When I sent the mail, I realized I forgot to talk about my DRM todo list. This was the number one issue I had.
Thanks for the suggestions, I will look into it promptly.
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 ...).
So, you mean some intel-oriented sw communicate the mapping offset between each others? That's ugly as hell!
I can't really comment on the other pieces of this due to lack of knowledge.
Thanks, I do not expect for every one to have some feedback on the whole patchset. I'm new to these user-space projects too...
Cheers, Daniel
Thanks for taking the time to answer me!
Cheers, Martin