After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 664256 - Separate video decoding in another process
Separate video decoding in another process
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
unspecified
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-11-17 10:31 UTC by Bastien Nocera
Modified: 2018-11-03 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2011-11-17 10:31:05 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
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2011-11-28 11:40:55 UTC
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.
Comment 2 Bastien Nocera 2011-12-01 22:53:05 UTC
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.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-02 07:34:27 UTC
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.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-02 07:43:23 UTC
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
Comment 5 David Schleef 2012-01-30 00:49:56 UTC
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.
Comment 6 Guillaume Emont (guijemont) 2012-05-04 11:17:59 UTC
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.
Comment 7 Guillaume Emont (guijemont) 2012-05-08 10:44:49 UTC
The aforementioned explanatory blog post is now written and online: http://guij.emont.org/blog/2012/05/08/video-decoding-in-a-sandbox/
Comment 8 Nicolas Dufresne (ndufresne) 2014-07-03 20:53:10 UTC
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.
Comment 9 GStreamer system administrator 2018-11-03 16:12:53 UTC
-- 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.