VK_EXT_aquire_xlib_display and kernel security concerns

[Keith Packard]

Andy Ritger <aritger at nvidia.com> writes:

> If the NVIDIA X driver finds an HMD display, it:
>
> (a) Marks it as disconnected.
> (b) Does not make its EDID available to RandR clients.
>
> So, unless I'm mistaken, RandR clients will see the HMD as an RandR
> output.  But, perhaps the problem is that the RandR client cannot tell
> that the output is an HMD, since the EDID is not available?

It will look like a regular disconnected output...

> Item (b) was only an artifact of how the code is structured, not an
> intentional decision.  To be fair, disconnected output with EDID sounds
> like a slightly odd state.

Well, the goal is to have regular X clients ignore the output, for which
reporting a Disconnected state seems the best way. The only question is
then how to report to 'special' clients that there is an HMD present on
the connector. We could:

 a) Create a new request to query 'hidden' outputs
 b) Report the 'connected' state in a new output property
 c) Let the client infer that a valid EDID indicates that
    a display is connected.

We would still send RROutputChangeNotify events when the device was
connected/disconnected so that applications could track the state of the
device, but of course the 'connection' status in that event would always
be Disconnected.

> Anyway, we can update the NVIDIA driver behavior to match whatever
> consensus we reach here.

Let's try to poke holes in the simple plan that Dave suggested above; I
can't see any offhand, but I haven't tried to implement it in the X
server or applications either.

Btw, was there any particular reason the acquire_xlib_display extension
used Xlib types instead of xcb types?

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171016/32fa3274/attachment-0001.sig>