[PATCH wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_hints

Simon Ser contact at emersion.fr
Tue Jun 18 10:03:18 UTC 2019

Note to self: compositors shouldn't dup() their FD when passing the
device FD.

12:44 <pq> GEM names are specific to the DRM device and to... the process? the result of open() syscall?
12:44 <ickle> fd
12:44 <pq> fd? so if I dup() a DRM device fd, the old GEM names are not valid on the dupped fd?
12:44 <ickle> sorry struct file
12:45 <pq> right, and struct file represents... what?
12:46 <ickle> an instance of the device
12:46 <pq> is a struct file created every time I open() a DRM device node?
12:46 <ickle> yes
12:46 <pq> gotcha, thanks!
12:47 <pq> wait... IOW, if a compositor passes its own DRM device fd via protocol to another process, that another process could brute-force all the GEM names the compositor has?
12:48 <ickle> yes
12:48 <pq> !
12:48 <ickle> hence why the compositor should not do that
12:48 <ickle> and pass a clean open(), preferably of the rendernode
12:48 <pq> that's pretty important catch
12:49 <pq> yeah, thinking about Wayland, there shouldn't be that going on in compositor at all, because so far it's just Mesa who sends device fds to clients.
12:49 <pq> but that's a huge catch really
12:49 <ickle> if it passed its own, not only does it get all the handles, but its get its permission and grants such as DRM_MASTER
12:50 <pq> whoa, of course
12:51 <pq> emersion, this ^ is pretty important for the wayland device hints implementations.
13:00 <ascent12> Probably worth explicitly mentioning that in the protocol as a warning to compositors.
13:00 <emersion> oh, indeed, thanks for the heads-up

More information about the wayland-devel mailing list