GNOME Bugzilla – Bug 664256
Separate video decoding in another process
Last modified: 2018-11-03 16:12:53 UTC
To cut down on the possible crashers in video applications, as well as to protect the system from security problems due to crafted videos that would be available on the Internet. This process could then be locked down based on technology available in particular systems, and with the process also setting itself up to be as frugal as possible. For reference, QuickTime's process separation: http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/9#privilege-separation Google Chrome's sandboxing: http://en.wikipedia.org/wiki/Google_Chrome#Security
You want playbin(2) to do that automatically? It can possibly be done using the shm plugins, but it will have quite a bit of overhead :/ Also out of process rendering of video is tricky.
How much is the overhead? Is the overhead mostly about copying data to and from the SHM segment? I guess this could always be opt-in, but my idea was, roughly, of a GstBin which would replicate the sinks/sources/pads of the element running inside a separate process. In some cases, the added security is probably more important than the performance cost (web browser). It would also mean that which actual plugins are running externally would be the decision of something like playbin2 (read in process, demux out of process, decode audio out of process, but video in hardware, etc.). I think this is definitely something to investigate, even if it is a hard problem.
Yes, the overhead is mostly the shm transport. A fully transparent implementation would be cool, but is not trivial. It would be great to have a let call it ProxyBin. It would register proxy gobject for each element (unless they have been already registered). It would need to launch the actual elements in a new process and establishing the proxy links between each of the elements. Might become complicated when done recursively. Ideally it could use libdataprotocol to marshal buffers, events, queries and messages. This could be a great GSoC project for next summer.
Bastien, another thought. Moving a partial pipeline to a separate process can e difficult when bin boundaries overlap. For totem I could see a much simpler solution: - have a out-of process head-less totem running a dbus service (MPRIS alike) - the oop totem uses shmsink as a video-sink - the real-totem uses shmsrc ! autovideosink - audio can be send from any process anyway
Wouldn't it be better to fix the decoders? It's really not that complicated. It's been done for both theora and schroedinger. Video decoders only have about 5 places where they need to be audited. After that, they're basically transforming from bounded array A to bounded array B, usually iterating over blocks in B. So it's *really* hard to get it to write outside its bounds. It's somewhat easier to create a stream that will cause an unaudited decoder to read outside its bounds, but that's not a path that leads to exploits. None of this affects the other reasons one might want to use out-of-process processing, which I think is a good idea. Just not to work around bugs.
I have more or less implemented this: https://github.com/guijemont/Sandboxed-Player In a nutshell, the sandboxeddecodebin element is a bin has inside: fdsink (sends stuff to sandboxed process) shmsrc (gets gdp encoded video buffers from sandboxed process) ! gdpdepay shmsrc (gets gdp encoded audio buffers from sandboxed process) ! gdpdepay And the external process runs a pipeline like: fdsrc ! decodebin2 name=decoder decoder. ! video/x-raw-yuv;video/x-raw-rgb ! gdppay ! shmsink (video) decoder. ! audio/x-raw-int;audio/x-raw-float ! gdppay ! shmsink (audio) The sandboxing is done using setuid-sandbox (a stand alone version of the chromium sandbox: http://code.google.com/p/setuid-sandbox/ ). This proves that it is doable, and can be used to measure the performance overhead (I haven't done that yet). I am in the process of writing up a blog post that explains this thing in more details.
The aforementioned explanatory blog post is now written and online: http://guij.emont.org/blog/2012/05/08/video-decoding-in-a-sandbox/
Also, this breaks any type of zero-copy between decoder and renderer. I think the solution will be much simpler when we get dmabuf, at that point we'd have to teach shmsrc/sink to pass FD rather then copying the data into own shm memory.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/10.