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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
