VK_EXT_aquire_xlib_display and kernel security concerns

[Keith Packard]

I've implemented this extension in DRM and have run into a conflict
between the spec and the Linux architecture.

The VkDisplayKHR parameter for VK_EXT_acquire_xlib_display can be
found in two different ways:

 1) Enumerate displays using vkGetPhysicalDeviceDisplayPropertiesKHR

 2) Enumerate RROutputs using xcb_randr_get_screen_resources and
    convert that to a VkDisplayKHR with vkGetRandROutputDisplayEXT

The former makes some assumptions which are not valid in all
environments:

 a) It assumes that the Vulkan rendering driver can touch all of the
    display resources on the system.

    Under DRM, a regular user running vulkan can only open a 'rendering'
    node, which denies it all access to the display resources associated
    with the rendering hardware.

 b) It assumes that the rendering driver knows about the display
    hardware.

    There are many modern systems where the display hardware and
    rendering hardware are entirely separate, and we must use DMAbufs to
    get the rendered output sent from the rendering driver to the
    display driver.

 c) It assumes that X controls all display resources on the system.

    If you're running more than one X server on different displays, then
    you can end up with a VkDisplayKHR object which the X server doesn't
    manage, and hence cannot be 'acquired'.

I can work around a) by opening up access rights to view display
resources to all applications with access to render nodes. I've had push
back on this plan from the DRM maintainers as it dramatically changes
the access control model used by DRM with unknown consequences for both
security and application abuse.

I can't work around b) and c) as the
vkGetPhysicalDeviceDisplayPropertiesKHR function doesn't have any
information about the window system to allow it to limit the set of
display resources to those shared by X and Vulkan.

Using method 2) provides the necessary control as
vkGetRandROutputDisplayEXT gets both the Vulkan and X contexts and can
make suitable choices about what it can support.

However, the reason vkAcquireXlibDisplay takes a VkDisplayKHR object
instead of an RROutput parameter is so that it can access displays which
X may not want to advertise to all clients. I don't think that's
necessary; we can advertise the RROutput, but just not tell clients
that it is "Connected" when the display shouldn't be incorporated into a
'normal 'desktop. A separate mechanism would be used to report Connected
status and describe what kind of device is out there.

So, here's what I propose:

vkGetPhysicalDeviceDisplayPropertiesKHR will fail when the
system does not provide access to display resources for unprivileged
Vulkan applications. When this happens, the application is expected to
discover the desired display resource through X and map that to a
VkDisplayKHR using vkGetRandROutputDisplayEXT.

Any VkDisplayKHR may be used with vkGetDisplayModePropertiesKHR.

Once vkAcquireXlibDisplay is called, all of the VK_KHR_display APIs will
work, but the resources visible will be restricted to the acquired
display and plane.

With this secondary mechanism, DRM-based systems will expose all of
their native functionality without compromising the current API design.

-- 
-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/20171014/5581d196/attachment.sig>