VK_EXT_aquire_xlib_display and kernel security concerns

[Keith Packard]

James Jones <jajones at nvidia.com> writes:

> I think at a lower level, we have different views of how
> vkGetPhysicalDeviceDisplayPropertiesKHR/VK_KHR_display works.
> vkGetPhysicalDeviceDisplayPropertiesKHR() is suppose to enumerate all
> the displays on a given device.

In many devices, the display controller and rendering hardware are
separate devices, so it's up to user space to figure out the connection
between them, and user DMAbufs to pass rendered output to the display.

> I assumed DRM drivers would try the display-capable node, then fall
> back to a render node if that failed.

No, they cannot as the display node is protected from normal user
access.

>   Everyone focuses on the direct-to-display swapchain portion of 
> VK_KHR_display, but the core of it is really just a display
> enumeration API.

Right, I think all I really need is to hand the driver a connection to
the X server and it can use that to enumerate the available displays
through the Vulkan API.

> For (c), I hope that after reading the above, there is no such 
> assumption.  Of course the app can't acquire such a display, but that 
> shouldn't be unexpected.  I had hoped that there would be a way to 
> enumerate "hidden" HMD displays using XRandR, and I thought you provided 
> that in your XRandR changes.

Yes, we're figuring out how to do that now. Dave has posted proposed
kernel patches to the list which adds an EDID-based quirk to mark HMD
displays as 'special'.

Our current thought is that we would list the 'special' outputs as
Disconnected, but provide an EDID property for them. That way, normal X
applications would continue to ignore them, but a special application
could still discover the target device using EDID information.

> It seems to be suggested below as well. If apps have that, they can
> use vkGetRandROutputDisplayEXT to map them to VkDisplayKHR objects,
> rather than the other way around.  That way, they could avoid an
> attempt to acquire a display from the wrong X server.

Yes, I have a test application which works this way. However, as the
nVidia driver is hiding HMD outputs from X applications, an application
wanting to support both nVidia and DRM drivers will have to try both
methods.

> FWIW, I think this would be great.  I don't see why enumeration should 
> be a privileged operation.  chmod +x the display directory please :-)

That was my initial plan, and it obviously works fine. Daniel Vetter
has a reasonable aversion to providing this kind of access; "bad things"
have happened in the past when we expose system information of this kind
to all applications.

Besides, this fails in the case where the display device and rendering
device are separate, so we end up needing another path for that anyways.

> Let me know if you have suggestions to improve the Vulkan APIs.

Would it be reasonable to add a new function to the acquire_xlib_display
extension that would let you pass the Display into the API before the
vkGetPhysicalDeviceDisplayPropertiesKHR call? That would offer the least
impact on applications using the API, allowing them to have a single
enumeration mechanism for both DRM and nVidia devices. Right now, the
pattern looks like:

        open X connection
        enumerate displays using vk APIs
        select desired display
        acquire xlib display

That would change to

        open X connection
        tell vk about the X connection
        enumerate displays using vk APIs
        select desired display
        acquire xlib display

Without this function, every application would have to try both
enumerations:

        open X connection
        enumerate displays using vk APIS
        if (success) {
                select desired display
        } else {
                enumerate outputs using X apis
                select desired output
                map output to display
        }
        acquire xlib display

Alternatively, we could encourage applications to always use X lib APIs
for selecting the output; there's more information provided about the
device from that interface (like the EDID). That would require that the
nVidia X driver not hide the HMD from X as it reportedly does today.

Oh, one added benefit of telling Vulkan about the X display is that it
could trim the list of outputs to those reachable by the rendering
driver; definitely a point in favor of that method. In this case, we
might want to extend the information made available through Vulkan to
things like EDID so that applications aren't left guessing which output
they want based solely on the display geometry.

-- 
-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/3c37f065/attachment.sig>