[RFC] drm: add unref_fb ioctl

[Daniel Vetter]

On Wed, May 10, 2017 at 1:24 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>> On Tue, May 9, 2017 at 5:36 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>> Disadvantages:
>>>>   * depending on userspace architecture, layers left on screen could
>>>>     be considered an information leak, ie. new incoming master process
>>>>     has access to buffers that are still being scanned out.
>>>
>>> I'm not sure this is much of a problem really, or at least I suspect
>>> we have bigger issues: the GETFB ioctl allows you to get at the gem bo
>>> behind any framebuffer, as long as you're the current master. There's
>>> no need for that framebuffer to be active on the screen. Not sure
>>> that's a good idea really, we might want to fix up that ioctl to only
>>> hand out the backing storage objects for currently active objects. But
>>> kinda separate issue.
>
> hmm, it would seem unusual for incoming process to inherit any fb's
> *other* than what is on screen (what else would be holding a ref to
> keep them live?)

This was an observation about the existing code, not your new ioctl.
If you vt-switch between different users, and the other X.org server
keeps framebuffer objects around after vt-leave, then the current
master can read the contents of those. I assume that userspace is not
100% dutiful with getting this right, and it might be easier to plug
this hole in the kernel. This is not about the case where the other
compositor quits, but keeps running in the background.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch