[RFC] Complete experimental render node implementation

[RFC] Complete experimental render node implementation

[Martin Peres]

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.

## 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

[RFC] Complete experimental render node implementation

[Martin Peres]

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.

## 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

Re: [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@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

Re: [RFC] Complete experimental render node implementation

[Martin Peres]

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