5 ms·

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh.

by jbk 12y ago

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh. > Do you think it be much work to spin security-conscious parts like the decoders into separate processes? Extremely difficult. We've thought about it. For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decoders. The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think). The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread. For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).

chubot 12y ago
The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process. EDIT, used to use: https://codereview.chromium.org/298443002/ https://codereview.chromium.org/298443002/ Still, it appears it used this method for a long time, so it seems feasible. Also, Chrome has multiple video playing paths, including Flash, which is sandboxed, so I don't see the difference. The Flash video has to be decoded in a sandbox. I imagine HTML5 video is sandboxed somehow too. It is very platform-specific and difficult, and performance is a prime concern, but not impossible.
- jbk 12y ago
  > Why not used shared memory? Because this is not normal shared memory, this is GPU shared memory. This is hard to port.
  - alexlarsson 12y ago
    Can you not use dma-buf and EXT_image_dma_buf_import?
    - jbk 12y ago
      Maybe, but that's quite not portable, and driver specific, AFAIK.
      - comex 12y ago
        Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it works with driver-mapped pages too.
        alexlarsson 12y ago
        Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.
        comex 12y ago
        If it's mapped into the CPU address space, then it can be shared. If not, then there is a copy going on and you may as well just do it in the non-sandboxed process, no?
        alexlarsson 12y ago
        There is no copy. You have a reference to a GPU side buffer, and you want to pass a reference to that buffer to another process, where it will continue to use the GPU to access it.
agwa 12y ago
> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing? In any case, it makes me really happy to know that you've thought about this!
- jbk 12y ago
  > I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing? It's GPU allocated memory, so not so sure. > In any case, it makes me really happy to know that you've thought about this! If you have ideas, we'd love to work on it, seriously.
alexlarsson 12y ago
> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread. Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way to do process splitting while sharing memory in a "safe" way. (i.e. the recieving side can guarantee that the sending side is not playing silly-buggers with the buffers while you read them). For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?
- jbk 12y ago
  > For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work? This is not portable, but this is a possible solution for Linux. But this is far from being ready, which is one of my main point :)
  - alexlarsson 12y ago
    Well, the sandboxing stuff is not ready either. We need work on all levels of the stack to make this stuff work.
Estragon 12y ago
I'm curious, have there been bugs in VLC which would allow arbitrary code execution on linux? What about the video player in google chrome?
- cocoablazing 12y ago
  VLC http://www.linuxsecurity.com/content/view/162615/ http://www.linuxsecurity.com/content/view/162615/
- jbk 12y ago
  Yes for both.

by jbk 12y ago

chubot 12y ago

The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process. EDIT, used to use: https://codereview.chromium.org/298443002/ https://codereview.chromium.org/298443002/ Still, it appears it used this method for a long time, so it seems feasible. Also, Chrome has multiple video playing paths, including Flash, which is sandboxed, so I don't see the difference. The Flash video has to be decoded in a sandbox. I imagine HTML5 video is sandboxed somehow too. It is very platform-specific and difficult, and performance is a prime concern, but not impossible.

jbk 12y ago
> Why not used shared memory? Because this is not normal shared memory, this is GPU shared memory. This is hard to port.
- alexlarsson 12y ago
  Can you not use dma-buf and EXT_image_dma_buf_import?
  - jbk 12y ago
    Maybe, but that's quite not portable, and driver specific, AFAIK.
    - comex 12y ago
      Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it works with driver-mapped pages too.
      - alexlarsson 12y ago
        Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.
        comex 12y ago
        If it's mapped into the CPU address space, then it can be shared. If not, then there is a copy going on and you may as well just do it in the non-sandboxed process, no?
        alexlarsson 12y ago
        There is no copy. You have a reference to a GPU side buffer, and you want to pass a reference to that buffer to another process, where it will continue to use the GPU to access it.

agwa 12y ago

> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing? In any case, it makes me really happy to know that you've thought about this!

jbk 12y ago
> I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing? It's GPU allocated memory, so not so sure. > In any case, it makes me really happy to know that you've thought about this! If you have ideas, we'd love to work on it, seriously.

alexlarsson 12y ago

> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread. Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way to do process splitting while sharing memory in a "safe" way. (i.e. the recieving side can guarantee that the sending side is not playing silly-buggers with the buffers while you read them). For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?

jbk 12y ago
> For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work? This is not portable, but this is a possible solution for Linux. But this is far from being ready, which is one of my main point :)
- alexlarsson 12y ago
  Well, the sandboxing stuff is not ready either. We need work on all levels of the stack to make this stuff work.

Estragon 12y ago

I'm curious, have there been bugs in VLC which would allow arbitrary code execution on linux? What about the video player in google chrome?

cocoablazing 12y ago
VLC http://www.linuxsecurity.com/content/view/162615/ http://www.linuxsecurity.com/content/view/162615/
jbk 12y ago
Yes for both.