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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
