[ Let's try this again... ]
Ok, so the flink_to discussion rat-holed a bit on the binary blob attachment issue. But before we even get to that, there are a lot of issues that I'd some feedback on as well. There were a few bugs in the patch that I've fixed, but I don't see the point in sending it out again just yet, as I'd like to see if we can agree on some of the higher level issues.
First of, I'm hoping we can get this ready for the next merge window. The patch is written and I've tested it here with a libdrm test case and am currently finishing the EGL support for this. One change I might want to do is to add a blob type argument to the ioctls so userspace has a standardized way of indication what the format of the data is (what Keith pointed out). That's a fairly simple change and the patch itself is simple enough to begin with, so I don't expect a lot of tricky issues with the implementation.
Along with the flink_to ioctl, I'm proposing that we drop the DRM_AUTH requirement for accessing the gem ioctls. Specifically, for intel, I'm suggesting that we drop the DRM_AUTH requirement on
DRM_IOCTL_GEM_FLINK, DRM_IOCTL_GEM_OPEN, DRM_I915_GEM_EXECBUFFER, DRM_I915_GEM_EXECBUFFER2, DRM_I915_GEM_BUSY, DRM_I915_GEM_THROTTLE, DRM_I915_GEM_CREATE, DRM_I915_GEM_PREAD, DRM_I915_GEM_PWRITE, DRM_I915_GEM_MMAP, DRM_I915_GEM_MMAP_GTT, DRM_I915_GEM_SET_DOMAIN, DRM_I915_GEM_SW_FINISH, DRM_I915_GEM_SET_TILING, DRM_I915_GEM_GET_TILING, DRM_I915_GEM_GET_APERTURE, DRM_I915_GEM_MADVISE,
which should allow clients to create buffers, submit rendering against them and share them with a priviledged (in the sense that it controls scanout) display server. Access to these ioctls will then only be guarded by the permissions on /dev/dri/cardX, which all distros restrict to the 'local' user (that is, excluding ssh and similar) in one way or another. How do we feel about that? Maybe it's something the master needs to request, so that only X servers that use flink_to will activate this mode?
flink_to doesn't in itself solve the security problem, since user space can still submit a batch buffer that reads or writes to an absolute gtt offset (that is, no relocation). The X front buffer location is typically pretty predictable, for example. flink_to does give us the infrastructure to implement a secure system though. There are several ways this could be done: use a sw command checker to reject absolute gtt offsets, unbind buffers from all other clients before running executing the commands or use per-process gtt or similar hw support.
Then there's the data passing mechanism part of flink_to. I'm suggesting that we allow applications to attach a blob to an flink_to name, which will be passed to the process calling open_with_data on the name. The format of the blob is defined by userspace, typically libdrm or mesa, and lets us marshal meta data about the buffer along with granting access to the buffer. And just to be clear, the kernel has no need for this meta data, it doesn't even understand the format. But it will make protocoles and user level APIs simpler, and it's not going to be a resource drain in the kernel. There's a 2k max size on the attached data, and a buffer can only have one flink_to name pending per file_priv. I didn't see any strong objections in the thread, but I understand the concerns. We're debating a minimal kernel API with a kludgey userspace vs kernel API with convenience features and much simpler userspace.
Anyway, I'll post an update when I get a working userspace on top of this proposal. In the meantime I would much appreciate feedback on the above issues.
Kristian