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@xxxxxxxxx> wrote: > >> On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > >>> On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > >>>> On Tue, May 9, 2017 at 5:36 PM, Rob Clark <robdclark@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
