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]

Message-ID: <87o9pc5bcf.fsf@keithp.com>
Date:   Thu, 12 Oct 2017 14:02:08 -0700
From:   "Keith Packard" <keithp@...thp.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     linux-kernel@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 2/6] drm: Allow render nodes to query display objects

Daniel Vetter <daniel@...ll.ch> writes:

> 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 ...

Yeah, it's the Vulkan EXT_acquire_xlib_display API which is using this
access to discover the set of resources available via the render fd in
preparation for accessing them over the lease fd once the lease has been
created.

I *think* I can get enough information to make a good guess as to what
kernel resources there are from the RandR info. I'll go give that a try
and see if I get stuck.

Thanks for the feedback; the fewer kernel API changes the better.

-- 
-keith

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)