Bugzilla

(In reply to Paul Menzel from comment #61)
> So what is the actual problem? Could a summary be added to the original description? Can this be worked around in the Intel driver?

Summary:
* iHD sometimes uses a syscall Firefox doesn't want to allow in the content process sandbox for a reason. An Intel developer promised to change the iHD driver.
* The ArchLinux wiki should unambiguously state that disabling the content process sandbox means disabling the protection against attackers. Don't ever disable the content process sandbox.
* VAAPI won't be moved to the RDD process (it will keep its tight sandbox), but to the GPU process. Then, current syscall might not even matter.
* A Wayland GPU process (based on dmabuf) will be implemented in the FF94 timeframe. So far there is only an X11 GPU process that has not been shipped yet due to a minor bug.
* As a workaround, most users can temporarily switch from the iHD VAAPI driver to the i965 VAAPI driver.
* Intel Iris Xe seems to be only supported by the iHD driver which means its users have to wait until the Wayland GPU process has been implemented and VAAPI been moved to the GPU process.

(Francois Guerraz from comment #0)
> syscall 64

(Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #12)
> The driver does in fact appear to be using SysV IPC; [here, for example][a-semget].  This is… not great; SysV IPC's security model is based only on uid/gid and as far as I know there's no way to use a broker to restrict access as we do with regular file accesses (by passing fds with `SCM_RIGHTS`).
> 
> [a-semget]: https://github.com/intel/media-driver/blob/1b48bb5df6e91e224b66c9bf1e9f7ab686b75e95/media_driver/linux/common/os/mos_os_specific.c#L626
> 
> We *might* be able to get away without completely allowing SysV IPC if the driver only ever uses fixed hard-coded `key_t` values, because those are just integers and can be filtered by seccomp-bpf.  (For example, `1140872792` seen in comment #7 is the value defined in the driver source as `#define DUAL_VDBOX_KEY ('D'<<24|'V'<<8|'X'<<0)`.)  This can even work on 32-bit x86 before kernel 4.3, because `ipc(2)`'s arguments are shifted by one, not passed in memory as for `socketcall(2)`.  However, it means we can't use `CLONE_NEWIPC`.  And of course it will break if the driver ever changes that implementation detail.
> 
> Something else I'd like to find out is what options we have for moving the use of this driver into another process, like the RDD or GPU process, so that the sandbox exception isn't exposed to the process that's executing untrusted JS.


(Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #19)
> For reference: Chromium has a compile-time option for VA-API, off by default, enabled in some downstream builds.  From the layout of their codebase it looks like they run it in their GPU process, which seems to allow unrestricted use of SysV IPC; Chromium's renderer processes, in contrast, do not allow it.  (Interestingly, they seem to use only seccomp-bpf filtering of the syscalls and don't unshare the IPC namespace.)
> 
> Allowing SysV IPC in the RDD process isn't ideal, but if the alternative is running ffmpeg in the GPU process: the GPU process currently doesn't have a sandbox on Linux, and its eventual sandbox would be weaker than for RDD, and the data immediately accessible to the RDD process would only be related to media decoding, not all of the browser's compositing.  So, the RDD process seems to be the better place for this.

Intel developer:
(Xinfeng Zhang from comment #46)
> the IPC is for gen9 vdbox balance,  need to record the task for each vdbox across process. now, we plan to change the logic to random dispatch. will remove these IPC call

(Martin Stránský [:stransky] (ni? me) from bug 1610199 comment #75)
> This bug a blocked by Bug 1683808 (and similar). The correct way forward here is to implement GPU process on Wayland (by dmabuf EGL framebuffer) and then implement VAAPI in GPU process as we actually can't use VAAPI in RDD process.

(Esokrarkose from bug 1683808 comment #23)
> Since I have the new Intel Iris Xe, I can't make use of the older i965 driver, thus I'm forced to the new iHD driver.

(In reply to Paul Menzel from comment #61)
> So what is the actual problem? Could a summary be added to the original description? Can this be worked around in the Intel driver?

Summary:
* iHD sometimes uses a syscall Firefox doesn't want to allow in the content process sandbox for a reason. An Intel developer promised to change the iHD driver.
* The ArchLinux wiki should unambiguously state that disabling the content process sandbox means disabling the protection against attackers. Don't ever disable the content process sandbox.
* VAAPI won't be moved to the RDD process (it will keep its tight sandbox), but to the GPU process. **Then, current syscall might not even matter.**
* A Wayland GPU process (based on dmabuf) will be implemented in the FF94 timeframe. So far there is only an X11 GPU process that has not been shipped yet due to a minor bug.
* As a workaround, most users can temporarily switch from the iHD VAAPI driver to the i965 VAAPI driver.
* Intel Iris Xe seems to be only supported by the iHD driver which means its users have to wait until the Wayland GPU process has been implemented and VAAPI been moved to the GPU process.

(Francois Guerraz from comment #0)
> syscall 64

(Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #12)
> The driver does in fact appear to be using SysV IPC; [here, for example][a-semget].  This is… not great; SysV IPC's security model is based only on uid/gid and as far as I know there's no way to use a broker to restrict access as we do with regular file accesses (by passing fds with `SCM_RIGHTS`).
> 
> [a-semget]: https://github.com/intel/media-driver/blob/1b48bb5df6e91e224b66c9bf1e9f7ab686b75e95/media_driver/linux/common/os/mos_os_specific.c#L626
> 
> We *might* be able to get away without completely allowing SysV IPC if the driver only ever uses fixed hard-coded `key_t` values, because those are just integers and can be filtered by seccomp-bpf.  (For example, `1140872792` seen in comment #7 is the value defined in the driver source as `#define DUAL_VDBOX_KEY ('D'<<24|'V'<<8|'X'<<0)`.)  This can even work on 32-bit x86 before kernel 4.3, because `ipc(2)`'s arguments are shifted by one, not passed in memory as for `socketcall(2)`.  However, it means we can't use `CLONE_NEWIPC`.  And of course it will break if the driver ever changes that implementation detail.
> 
> Something else I'd like to find out is what options we have for moving the use of this driver into another process, like the RDD or GPU process, so that the sandbox exception isn't exposed to the process that's executing untrusted JS.


(Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #19)
> For reference: Chromium has a compile-time option for VA-API, off by default, enabled in some downstream builds.  From the layout of their codebase it looks like they run it in their GPU process, which seems to allow unrestricted use of SysV IPC; Chromium's renderer processes, in contrast, do not allow it.  (Interestingly, they seem to use only seccomp-bpf filtering of the syscalls and don't unshare the IPC namespace.)
> 
> Allowing SysV IPC in the RDD process isn't ideal, but if the alternative is running ffmpeg in the GPU process: the GPU process currently doesn't have a sandbox on Linux, and its eventual sandbox would be weaker than for RDD, and the data immediately accessible to the RDD process would only be related to media decoding, not all of the browser's compositing.  So, the RDD process seems to be the better place for this.

Intel developer:
(Xinfeng Zhang from comment #46)
> the IPC is for gen9 vdbox balance,  need to record the task for each vdbox across process. now, we plan to change the logic to random dispatch. will remove these IPC call

(Martin Stránský [:stransky] (ni? me) from bug 1610199 comment #75)
> This bug a blocked by Bug 1683808 (and similar). The correct way forward here is to implement GPU process on Wayland (by dmabuf EGL framebuffer) and then implement VAAPI in GPU process as we actually can't use VAAPI in RDD process.

(Esokrarkose from bug 1683808 comment #23)
> Since I have the new Intel Iris Xe, I can't make use of the older i965 driver, thus I'm forced to the new iHD driver.