VK_EXT_aquire_xlib_display and kernel security concerns

James Jones jajones at nvidia.com
Tue Oct 17 14:39:56 UTC 2017


On 10/16/2017 05:49 PM, Keith Packard wrote:
> 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?

That's just what was asked for IIRC.  There could be a 
VK_EXT_acquire_xcb_display, VK_EXT_acquire_wayland_display, 
VK_EXT_acquire_win32_display, etc. as demand dictates.

Thanks,
-James


More information about the xorg-devel mailing list