[RFC] drm: add unref_fb ioctl

[Daniel Vetter]

On Thu, May 11, 2017 at 04:45:09PM +0900, Michel Dänzer wrote:
> On 10/05/17 10:16 PM, Daniel Vetter wrote:
> > 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.
> 
> Even with your suggested change though, the new master would presumably
> be able to access at least the last FBs scanned out by the old master?
> The old master could only prevent that by turning off all CRTCs, which
> would make VT switching ugly and slow.

RMFB is nothing else than the proposed CLOSEFB here plus disabling all
CRTC (if the fb shows somewhere). VT switching is still slow if you want
to make sure your fbs don't show up anywhere, whether the kernel shuts
down the display for you, or whether you do it explicitly.

The idea behind CLOSEFB is that you switch to an fb without anything
interesting on it (fade to black), then CLOSEFB (but leave the CRTC on),
so that the other compositor can take over without a full modeset.

Atm you have to do that by keeping the fb around until after the other
compositor has taken over, which is kinda silly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch