linux-kernel - Re: [PATCH 2/6] drm: Allow render nodes to query display objects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Oct 2017 21:45:43 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Keith Packard <keithp@...thp.com>, linux-kernel@...r.kernel.org,
        Dave Airlie <airlied@...hat.com>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 2/6] drm: Allow render nodes to query display objects

On Thu, Oct 12, 2017 at 08:41:17PM +0200, Daniel Vetter wrote:
> Hi Keith,
> 
> On Tue, Oct 10, 2017 at 05:48:27PM -0700, Keith Packard wrote:
> > This allows an application to discover what display resources are
> > available before requesting a lease from the X server.
> > 
> > Signed-off-by: Keith Packard <keithp@...thp.com>
> 
> For reasons I've kidna stopped reviewing these patches. I don't really
> agree with the details of the lease uapi as implemented. But that's
> nothing that can't be fixed with a few flags, and leases always need an
> explicit opt-in from the compositor now, so still possible to do
> reasonable architecture on top in the future. Worst case we fake just the
> parts that X needs from this version of leases, we've done that kind of
> stuff in the past.
> 
> This here otoh is an uapi change that we can't ever undo or contain,
> because as soon as we allow anyone to read kms state they will do so. And
> do so in lots of very interesting and abusive ways. E.g. there's already
> apps who try to second-guess the vblank timings with the vblank ioctl
> (which accidentally works everywhere, not just on the master), and ofc get
> it wrong, except for the case the developer tested on. Or without
> uevent/udev events you can't do efficient output probing, which means
> we'll see endless amounts of polling (we had to stop giving accurate data
> in the sysfs interface already, for exactly this reasons, because someone
> thought polling outputs once per second was a smart idea).
> 
> So given the huge possibilities of abuse, do we really, really need all
> this, and is there not any way to create a bit of protocol to pass the
> relevant data from X to clients? From your presentation is sounded like
> current xrandr is (almost) there ...

One more that came up on irc after discussion why this is needed: The
userspace side using this won't work on split gpus where the render node
has 0 displays, and hence where you really need to query the compositor
anyway.

Like I predicted, we expose this, everyone will abuse it in slightly
broken ways :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch