[RFC v2] Revive the work on render-nodes branch

[Kristian Høgsberg]

On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie <airlied at gmail.com> wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> <ihadzic at research.bell-labs.com> wrote:
>> The following set of patches is the reword of the series
>> sent two weeks ago [2] that will revive the drm-render-nodes [1]
>> branch. Details of the original series are described in [2].
>
> Thanks for looking at this,
>
> So one thing about adding render nodes, is it gives us the chance to
> maybe change the userspace API we expose to be more secure and have
> less cruft in it.
>
> Now I'm weary of a major API redesign as this could bog things now and
> we'd never make forward progress, but I'd like to at least consider it
> before adding new device nodes and locking us into the old APIs.
>
> The areas suggested before:
>
> 1) GEM, drop flink/open ioctls - these make security hard, since once
> you share a buffer any GEM opener can get access to it. Solutions to
> this proposed before are flink_to and maybe using PRIME/dma-buf.

Yup, and I retract my flink_to proposal.  Passing the buffer as an fd
has a few benefits over the flink_to idea: 1) we don't have to
establish an id/handle that represents the other process.  We could
use the process ID or the drm magic, but either way we'd need an
initial handshake to pass that id across before we can share buffer.
Not a deal breaker, just awkward.  2) Passing buffers as fds keeps the
buffer alive "in flight".  This allows the sender to send the buffer
and immediately destroy it, if it needs to.

Another thing I'd change for render nodes is to not require
authentication.  We can still protect access to render nodes to local
sessions using file system permissions (ie, you won't be able to ssh
in and start a GPGPU jobs).  Being able to use the drm device doesn't
give you access to the xserver frontbuffer like it did in the DRI1
days.  You can only render to your own buffers and send or receive
buffer handles over sockets.  If we restrict the ioctls to just GEM
and PRIME, I don't think authentication protects anything we couldn't
just use file system permission for instead.

> 2) master/device ownership. We might be able to drop the first opener
> is magically master, and require openers to ask for it somehow.

If we add render nodes that clients are expected to use, we can
restrict access to the legacy drm device node, such that only X can
open it.  That way it wouldn't matter too much whether we keep the
auto-master behavior or not.  I would like to see the root requirement
dropped from the drop and set master ioctls so that you could put X,
weston etc in a group that allows them to open /dev/dri/card0 and not
need root to perform vt switching duties.  Even today there's no need
for the root requirements, certainly drop master is harmless and
setmaster can just be restricted to drm fds that were previously
masters and only when there's no current master.

> 3) drop the old map ioctls from this interface, irq by busid, drop the AGP.

Yup, or another way to put it: what todays mesa needs, minus flink_to,
open, get_magic (this is the only libdrm call in the glx dri and
egl_dri2 loaders btw) , auth_magic, but with the PRIME ioctls added.

> I'm not talking about changing ioctl operation, more about introducing
> new ioctls and not allowing the old ones on the new nodes.

Yup, agree.

thanks,
Kristian