VK_EXT_aquire_xlib_display and kernel security concerns

[Keith Packard]

James Jones <jajones at nvidia.com> writes:

> Understood.  In that case, no displays should be enumerated on the 
> "rendering hardware" device in Vulkan, unless the driver vendor opts for 
> heroics.

We try to avoid software heroics where possible.

> Right, but normal processes don't need the display node, or aren't 
> supposed to.  I assumed apps that need direct-to-display would have 
> elevated permissions on systems configured to require it, or use 
> "acquire" extensions, potentially combined with native secondary auth 
> mechanisms, to get access.  This is why it bothers me that "normal user 
> access" doesn't include display enumeration.

Imagine a multi-user setup where each display server controls only a
subset of the available resources. In that configuration, an application
would enumerate the available resources using the display server and
would not attempt to use resources assigned to another user.

For privileged users, I've proposed an extension which passes the master
FD into Vulkan as the instance is created. The implementation would then
use this to directly enumerate the display resources for use without the
acquire_xlib_display extension.

> Once a method is finalized to expose HMDs without having desktops pick 
> them up, we can probably switch to that behavior.  We'll have to review 
> the proposed disconnected-but-has-EDID idea above.  Currently, we have 
> an option to force exposure of HMDs, but then they just look like normal 
> displays to userspace.

That sounds entirely compatible -- when 'visible', the connected status
becomes active again.

> Is the discussion with Daniel Vetter captured somewhere so I can read
> up on the objections?  I couldn't find it with a naive Google or DRI
> devel search.

It was part of the kernel review of the proposed DRM lease mechanism:

https://www.spinics.net/lists/dri-devel/msg154108.html

> However, if there are one or two commands that could benefit from a
> display connection, an alternative design would be to make an
> extension that provides the connection info to those commands and
> scope it's availability to Vulkan to be the duration of those
> commands.

Hrm. The device need not retain persistent access to the X connection;
it could enumerate all of the resources necessary for the rest of the
API each time it is called. Essentially, the application would need to
call it each time it wanted to bring that cached information up to
date. That seems like a bit of a bodge; the question is whether it's
worth duplicating the enumeration APIs to avoid this.

Here's a proposed list of APIs which would need to be duplicated with
an additional argument:

vkGetPhysicalDeviceDisplayPropertiesKHR
vkGetPhysicalDeviceDisplayPlanePropertiesKHR
vkGetDisplayPlaneSupportedDisplaysKHR
vkGetDisplayModePropertiesKHR

Note that we would have to duplicate these again to support another
display server.

> Note I still don't think it's a good idea to enumerate outputs not
> reachable by the rendering device anyway, so I don't see this as a
> positive for telling Vulkan more about X.

Agreed -- that's a point in favor of having the enumeration done through
the existing Vulkan API with the addition of a connection to the display
server -- the Vulkan implementation would then be free to trim the list
down to those devices it can reach.

I've proposed adding a 'CONNECTOR_ID' property to each output in the
xf86-video-modesetting driver so that Vulkan can map between X outputs
and DRM connectors. I'd think the nVidia driver could do something
similar so that it would know which X resources were reachable from the
nVidia renderer.

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