[upstream] RDD sandbox prevents HW-accelerated video playback

[Aditya Suseno]

• Ubuntu 21.10 (64 bit)
• Firefox 98 installed via apt (cookies & cache have been cleared)
• Kernel 5.13.0-30-generic x86_64
• Tried on both wayland and X11 session → same result

Steps to reproduce:
(1) Visit https://www.youtube.com
(2) Choose one of the video

Actual Result: Video doesn't play

What Expected: Video Play normally

Previously it was normal on Firefox 97 (apt version)

Tried installing Firefox 98 Snap version and it works normally

[Stransky (stransky)]

We can't create GL context in RDD process which leads to missing video snapshots. It generally brings back Bug 1712588.

What's broken:
- we can't take video snapshots (context menu -> take snapshot)
- bookmarked page with video context is black
- D&D of tabs with video playback is black

[Stransky (stransky)]

Some details were provided to Bug 1724385 which also depends on this one.

Run with MOZ_SANDBOX_LOGGING=1 gives me:

Sandbox: Failed errno -2 op stat flags 00 path /tmp/Temp-d7ba8966-a234-4d30-9fb1-41087569e0c9/mesa_shader_cache
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libEGL.so
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGLdispatch.so.0
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGL.so
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGLX.so.0
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=40950
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=40950
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d
[GFX1]: Failed to create snapshot GLContext.

Reproduction steps are fairly easy, play a video clip on a page and try to bookmark it or move by D&D.

[Robert Mader (robert.posteo)]

Dupe of bug 1749623?

[Stransky (stransky)]

*** Bug 1749623 has been marked as a duplicate of this bug. ***

[W-jan-k (w-jan-k)]

Gnome Wayland, Debian Testing, Intel

bug 1752282 comment 16: Since bug 1724385, VAAPI seems to require GL context in RDD, otherwise won't work anymore.
Workaround is MOZ_DISABLE_RDD_SANDBOX=1.

Expected: `sudo intel_gpu_top` has hw video decoding workload.
Actual: It doesn't have.
STR (for X11/Xwayland with Mesa >=21 or Wayland):
MOZ_SANDBOX_LOGGING=1 MESA_GLSL_CACHE_DISABLE=1 mozregression --repo autoland --launch [d87eb81f8495](https://bugzilla.mozilla.org/show_bug.cgi?id=1752282#c18) --pref media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -P stdout
> 0:32.28 INFO: b'libva info: va_openDriver() returns 0'
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/graphics/fb0 for pid=17557'
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0'
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libEGL.so'
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGLdispatch.so.0'
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGL.so'
> 0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGLX.so.0'
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=17557'
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d'
> 0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=17557'
> 0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d'

[Stransky (stransky)]

*** Bug 1753390 has been marked as a duplicate of this bug. ***

[Aosmond (aosmond)]

*** Bug 1755526 has been marked as a duplicate of this bug. ***

[W-jan-k (w-jan-k)]

*** Bug 1755607 has been marked as a duplicate of this bug. ***

[Release-mgmt-account-bot (release-mgmt-account-bot)]

Set release status flags based on info from the regressing bug 1724385

[W-jan-k (w-jan-k)]

*** Bug 1758431 has been marked as a duplicate of this bug. ***

[W-jan-k (w-jan-k)]

*** Bug 1758613 has been marked as a duplicate of this bug. ***

[Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00)]

Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.ffmpeg.vaapi.enabled" in "about:config", might try disabling the sandbox feature as a workaround to keep video acceleration.

[Evilpies (evilpies)]

*** Bug 1758738 has been marked as a duplicate of this bug. ***

[Evilpies (evilpies)]

Workaround: Start Firefox with MOZ_DISABLE_RDD_SANDBOX=1. (This decreases security)

[Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00)]

I'm using that workaround now: If I start FF with "export MOZ_DISABLE_RDD_SANDBOX=1;kstart5 firefox" from a console, I can keep video acceleration enabled and everything plays back fine again. You can also put that export in your ~/.profile file so it's applied system wide, wouldn't recommend that though as you're likely to forget about it and I understand this may translate into less security.

[Mel34 (mel34)]

(In reply to Tom Schuster [:evilpie] from comment #13)
> Workaround: Start Firefox with MOZ_DISABLE_RDD_SANDBOX=1. (This decreases security)

Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?

[peng shao (shallpion)]

(In reply to Mel from comment #15)
> Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?

It asks to create a new profile and it may be inconvenient for some users

[W-jan-k (w-jan-k)]

Don't downgrade because security bugs have been fixed.
The workaround only disables the sandbox for a process that contains fuzzed media decoders, javascript is still sandboxed in its content process.
Personally I don't use the workaround and just wait for this bug to be fixed.

[Steindaimar (steindaimar)]

> Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.ffmpeg.vaapi.enabled" in "about:config", might try disabling the sandbox feature as a workaround to keep video acceleration.

Can confirm this happening, specially with Twitch, as it constantly keeps crashing with Error #3000. Other sites work normally on my experience and disabling `media.ffmpeg.vaapi.enabled` does solve the problem, but yeah, no luck with VA-API in the current state.

`MOZ_DISABLE_RDD_SANDBOX=1` does not solve the issue for me, at least using the Flatpak version of Firefox on Wayland.

Using `MOZ_LOG="PlatformDecoderModule:5"` I get:
`[Child 336: Main Thread]: D/PlatformDecoderModule FFMPEG: VA-API FFmpeg is disabled by platform`

But when I try to play a video the logs seem to treat like VA-API is working correctly in the beginning:
```
[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX: Initialising VA-API FFmpeg decoder
[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX: Format vp9 is accelerated
[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX: codec vp9 : Google VP9
[Child 410: MediaPDecoder #1]: V/PlatformDecoderModule AudioTrimmer[7f8448a792e0] ::PrepareTrimmers: sample[0,21000] no trimming information
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule OpusDataDecoder[7fbcd8a88800] ::Decode: Opus decoder skipping 312 of 960 frames
libva info: VA-API version 1.12.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
[Child 410: MediaPDecoder #2]: V/PlatformDecoderModule AudioTrimmer[7f8448a792e0] ::HandleDecodedResult: sample[0,21000] (decoded[0,13500] no trimming needed
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0
```

But I eventually get this error:
`[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule failed to create texture over DMABuf memory!`

Which leads to these messages and after that it falls back to regular FFmpeg decoder:

```
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: deleting dmabuf surface UID = 1
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 1
```

[Tempel-julian (tempel-julian)]

It doesn't even work with MOZ_DISABLE_RDD_SANDBOX=1 for me with 99.b1 (works with 98).

[Evilpies (evilpies)]

*** Bug 1759109 has been marked as a duplicate of this bug. ***

[Ajtbecool (ajtbecool)]

What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.

[Igarcia1089 (igarcia1089)]

Can confirm issue on Fedora 35. I just updated to Firefox 98 and VA-API HW acceleration is not working. It was working fine on Firefox 97.

[Evilpies (evilpies)]

Comment 18 (Daimar Stein) and comment 19 (walmartguy) please open new bugs or check if there is an existing similar bug, this bug is *only* about VAAPI not working because of sandboxing.

> What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.

It's hard to quantify. Thanks to VA-API decoding now happening in its own RDD process exploitation gets hard of course. But having no sandbox at all obviously makes it trivial to take over everything if an exploit is found.

[Aditya Suseno (aditya-suseno)]

Package: firefox
Version: 98.0+build3-0ubuntu0.21.10.2
Priority: optional
Section: web
Origin: Ubuntu
Maintainer: Ubuntu Mozilla Team <email address hidden>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 232 MB
Provides: gnome-www-browser, iceweasel, www-browser
Depends: lsb-release, libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.34), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libdbus-1-3 (>= 1.9.14), libdbus-glib-1-2 (>= 0.78), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.10.1), libgcc-s1 (>= 3.3), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.42), libgtk-3-0 (>= 3.14), libharfbuzz0b (>= 0.6.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libstdc++6 (>= 11), libx11-6, libx11-xcb1 (>= 2:1.7.2), libxcb-shm0, libxcb1, libxcomposite1 (>= 1:0.4.5), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6, libxrandr2 (>= 2:1.4.0), libxrender1, libxtst6
Recommends: xul-ext-ubufox, libcanberra0, libdbusmenu-glib4, libdbusmenu-gtk3-4
Suggests: fonts-lyx
Replaces: kubuntu-firefox-installer
Task: kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi
Xul-Appid: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Download-Size: 62.6 MB
APT-Sources: http://archive.ubuntu.com/ubuntu impish-updates/main amd64 Packages
Description: Safe and easy web browser from Mozilla
 Firefox delivers safe, easy web browsing. A familiar user interface,
 enhanced security features including protection from online identity theft,
 and integrated search let you get the most out of the web.

[Stransky (stransky)]

*** Bug 1759464 has been marked as a duplicate of this bug. ***

[Evilpies (evilpies)]

*** Bug 1760514 has been marked as a duplicate of this bug. ***

[JORGETECH (jorgetech)]

I can confirm this issue affects me in Firefox 98.0.1 (Kubuntu 21.10, AMD Ryzen iGPU with Mesa 22.0.0).

Playing a YouTube video makes the browser crash or not load the video and I get this on the console output:
```
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_14
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/libdrm/amdgpu.ids: Permission denied
```
I had to set the media.rdd-process.enabled flag to false to fix it, this was after updating Firefox, it didn't do this before.

I'm surprised this change landed in an stable release.

[Release-mgmt-account-bot (release-mgmt-account-bot)]

The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates, 13 votes and 78 CCs.
:gcp, could you consider increasing the bug severity?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

[Gpascutto (gpascutto)]

>I'm surprised this change landed in an stable release.

The feature is marked as disabled in Firefox 98.

[Gpascutto (gpascutto)]

>The feature is marked as disabled in Firefox 98.

And indeed it is: https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#8915

So to answer the question: nothing "landed in a stable release", this configuration was never supported nor released yet because of bugs like this one.

[Iamtrazy (iamtrazy)]

please consider increasing the severity of this bug , this still happens on both amd and intel on firefox 98.0.2 , hardware accelerations worked perfectly fine before 98 update without disabling rdd sandbox.

[Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00)]

I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

[Julian Sikorski (belegdol)]

(In reply to <email address hidden> from comment #31)
> I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

Just disable VAAPI and you will be able to watch videos just fine. On my machine (Ryzen 4500U) the difference in CPU load when watching youtube is minimal anyway. Please keep in mind that hardware acceleration was never officially enabled in release builds so please adjust your expectations accordingly.

[RussianNeuroMancer (russianneuromancer)]

> Just disable VAAPI and you will be able to watch videos just fine.

Some hardware cannot handle anything above 480p on YouTube unless hardware acceleration is enabled and works.

[Jay Chu (escape0707)]

(In reply to <email address hidden> from comment #31)
> I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

For now, set the media.rdd-process.enabled flag to false, or set the environment variable in proper files.

[Mav (basic89)]

(In reply to Jay Chu from comment #34)
> (In reply to <email address hidden> from comment #31)
> > I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.
>
> For now, set the media.rdd-process.enabled flag to false, or set the environment variable in proper files.

This is helpful, thank you. Nevertheless, most "normal" users will never find this topic, neither the config page. Firefox won't work for everyday use for them (consider the popularity of video streaming) and they will be switching to a browser that works. With AMD and intel GPUs common nowadays, we are talking a significant exodus of firefox users towards alternatives. Current P3 priority absolutely does not cut it.

[Pmenzel+bugzilla-mozilla-org (pmenzel+bugzilla-mozilla-org)]

@EvilMav, nobody disagrees, but it’s unrelated to the bug report. Firefox is FLOSS, so you can fix it or pay somebody. As long as users don’t support Firefox financially (donate or buy commercial GNU/Linux distribution licenses like RHEL desktop) so more developers can be paid to work on Firefox under GNU/Linux in full-time, the current state won’t change. But as written, it’s off-topic.

[Olivier Tilloy (osomon)]

Aditya, can you check whether libavcodec58 is installed? If it isn't, please install that package, then restart firefox, and let us know whether this fixed the problem.

[Gpascutto (gpascutto)]

I'm updating the flags just to make it clear we are in fact already working on this, see also https://bugzilla.mozilla.org/show_bug.cgi?id=1743926#c3.

[Aditya Suseno (aditya-suseno)]

sudo apt install libavcodec58

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libavcodec58 is already the newest version (7:4.4-6ubuntu5).
libavcodec58 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Seems that it's already installed
What about the behaviour in other machine (on ubuntu that is using apt)?

[Aditya Suseno (aditya-suseno)]

From the debug information, I suspect that the problem is on /usr/lib/x86_64/dri/radeonsi_drv_video.so
My machine is AMD® Ryzen 5 5600g with integrated radeon graphics by the way

There was an update for Firefox 98.0.2
Haven't tried the apt version for the 98.0.2

Will tried that this night, hopefully the problem disappear on this new update.

[Aditya Suseno (aditya-suseno)]

Still the same for Firefox 98.0.2

[Aditya Suseno (aditya-suseno)]

But sometimes, what you need is just reloading the page

[Olivier Tilloy (osomon)]

From the error messages, the problem seems to be with reading /usr/share/libdrm/amdgpu.ids, rather than loading the driver itself. What are the permissions on that file? Is an apparmor profile enforced for firefox?

[Aditya Suseno (aditya-suseno)]

/usr/share/libdrm$ ls -l

-rw-r--r-- 1 root root 10551 Jul 2 2021 amdgpu.ids

[Stransky (stransky)]

*** Bug 1759842 has been marked as a duplicate of this bug. ***

[Aditya Suseno (aditya-suseno)]

And this is the content of amdgpu.ids
It's just a plain text file

# List of AMDGPU IDs
#
# Syntax:
# device_id, revision_id, product_name <-- single tab after comma

1.0.0
15DD, C3, AMD Radeon(TM) Vega 3 Graphics
15DD, CB, AMD Radeon(TM) Vega 3 Graphics
15DD, CE, AMD Radeon(TM) Vega 3 Graphics
15DD, D8, AMD Radeon(TM) Vega 3 Graphics
15DD, CC, AMD Radeon(TM) Vega 6 Graphics
15DD, D9, AMD Radeon(TM) Vega 6 Graphics
15DD, C2, AMD Radeon(TM) Vega 8 Graphics
15DD, C4, AMD Radeon(TM) Vega 8 Graphics
15DD, C8, AMD Radeon(TM) Vega 8 Graphics
15DD, CA, AMD Radeon(TM) Vega 8 Graphics
15DD, D1, AMD Radeon(TM) Vega 8 Graphics
15DD, D5, AMD Radeon(TM) Vega 8 Graphics
15DD, D7, AMD Radeon(TM) Vega 8 Graphics
15DD, C3, AMD Radeon(TM) Vega 10 Graphics
15DD, D0, AMD Radeon(TM) Vega 10 Graphics
15DD, C1, AMD Radeon(TM) Vega 11 Graphics
15DD, C6, AMD Radeon(TM) Vega 11 Graphics
15DD, C9, AMD Radeon(TM) Vega 11 Graphics
15DD, D3, AMD Radeon(TM) Vega 11 Graphics
15DD, D6, AMD Radeon(TM) Vega 11 Graphics
15DD, 81, AMD Ryzen Embedded V1807B with Radeon Vega Gfx
15DD, 82, AMD Ryzen Embedded V1756B with Radeon Vega Gfx
15DD, 83, AMD Ryzen Embedded V1605B with Radeon Vega Gfx
15DD, 85, AMD Ryzen Embedded V1202B with Radeon Vega Gfx
15D8, 93, AMD Radeon(TM) Vega 1 Graphics
15D8, C4, AMD Radeon(TM) Vega 3 Graphics
15D8, C5, AMD Radeon(TM) Vega 3 Graphics
15D8, CC, AMD Radeon(TM) Vega 3 Graphics
15D8, CE, AMD Radeon(TM) Vega 3 Graphics
15D8, CF, AMD Radeon(TM) Vega 3 Graphics
15D8, D4, AMD Radeon(TM) Vega 3 Graphics
15D8, DC, AMD Radeon(TM) Vega 3 Graphics
15D8, DD, AMD Radeon(TM) Vega 3 Graphics
15D8, DE, AMD Radeon(TM) Vega 3 Graphics
15D8, DF, AMD Radeon(TM) Vega 3 Graphics
15D8, E3, AMD Radeon(TM) Vega 3 Graphics
15D8, E4, AMD Radeon(TM) Vega 3 Graphics
15D8, A3, AMD Radeon(TM) Vega 6 Graphics
15D8, B3, AMD Radeon(TM) Vega 6 Graphics
15D8, C3, AMD Radeon(TM) Vega 6 Graphics
15D8, D3, AMD Radeon(TM) Vega 6 Graphics
15D8, A2, AMD Radeon(TM) Vega 8 Graphics
15D8, B2, AMD Radeon(TM) Vega 8 Graphics
15D8, C2, AMD Radeon(TM) Vega 8 Graphics
15D8, C9, AMD Radeon(TM) Vega 8 Graphics
15D8, CB, AMD Radeon(TM) Vega 8 Graphics
15D8, D2, AMD Radeon(TM) Vega 8 Graphics
15D8, D9, AMD Radeon(TM) Vega 8 Graphics
15D8, DB, AMD Radeon(TM) Vega 8 Graphics
15D8, A1, AMD Radeon(TM) Vega 10 Graphics
15D8, B1, AMD Radeon(TM) Vega 10 Graphics
15D8, C1, AMD Radeon(TM) Vega 10 Graphics
15D8, D1, AMD Radeon(TM) Vega 10 Graphics
15D8, C8, AMD Radeon(TM) Vega 11 Graphics
15D8, CA, AMD Radeon(TM) Vega 11 Graphics
15D8, D8, AMD Radeon(TM) Vega 11 Graphics
15D8, DA, AMD Radeon(TM) Vega 11 Graphics
15D8, 91, AMD Ryzen Embedded R1606G with Radeon Vega Gfx
15D8, 92, AMD Ryzen Embedded R1505G with Radeon Vega Gfx
15D8, CF, AMD Ryzen Embedded R1305G with Radeon Vega Gfx
15D8, E4, AMD Ryzen Embedded R1102G with Radeon Vega Gfx
6600, 0, AMD Radeon HD 8600/8700M
6600, 81, AMD Radeon (TM) R7 M370
6601, 0, AMD Radeon (TM) HD 8500M/8700M
6604, 0, AMD Radeon R7 M265 Series
6604, 81, AMD Radeon (TM) R7 M350
6605, 0, AMD Radeon R7 M260 Series
6605, 81, AMD Radeon (TM) R7 M340
6606, 0, AMD Radeon HD 8790M
6607, 0, AMD Radeon (TM) HD8530M
6608, 0, AMD FirePro W2100
6610, 0, AMD Radeon HD 8600 Series
6610, ...

[Aditya Suseno (aditya-suseno)]

The same bug? @osomon

https://www.reddit.com/r/firefox/comments/t9s7mj/playing_videos_in_arch_linux_suddenly_fails_with/

[Alwu (alwu)]

*** Bug 1762384 has been marked as a duplicate of this bug. ***

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

*** Bug 1761490 has been marked as a duplicate of this bug. ***

[Kaypa (kaypa)]

updated to v99 on arch and MOZ_DISABLE_RDD_SANDBOX=1 workaround is not valid anymore

[Lucas Rizzini da Costa Lima (lucasrizzini)]

Same behavior here. https://www.reddit.com/r/linuxquestions/comments/tx7zou/firefox_99_crashing_with_hardware_decoding_using/

[Full system specs](https://github.com/rizzini/Dotfiles/tree/master/Documentos/hardware_specs).

[Kaypa (kaypa)]

(In reply to kaypa from comment #41)
> updated to v99 on arch and MOZ_DISABLE_RDD_SANDBOX=1 workaround is not valid anymore

looks like it's working again in nightly and has been fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1758610

not sure though

(don't know how to edit my comment sorry)

[Irxil (irxil)]

Still having issues with the latest nightly on my end. Running 101.0a1 (2022-04-05) and I see a small increase in video decode usage (using Intel GPU Top) when the [Big Buck Bunny video](https://www.youtube.com/watch?v=aqz-KE-bpKQ) loads (using 4k vp9 which is supported by my Tiger Lake laptop) but then it goes back to zero immediately and there's no further acceleration.

In the console, the following lines repeat themselves multiple times when the Youtube page is loaded:
```
libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
```
Looks like it is loading Vaapi properly but still not getting processed by the GPU.

[Irxil (irxil)]

When I run Firefox Nightly with `MOZ_SANDBOX_LOGGING=1` I get the following:

```
Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/graphics/fb0 for pid=11438
Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libEGL.so
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGLdispatch.so.0
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGL.so
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGLX.so.0
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=11438
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=11438
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=1102 perms=0 path=/etc/igfx_user_feature.txt for pid=11438
Sandbox: Failed errno -13 op open flags 01102 path /etc/igfx_user_feature.txt
```

[Lxsq131 (lxsq131)]

Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
`MOZ_DISABLE_RDD_SANDBOX=0 firefox-trunk
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: va_openDriver() returns 0
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: va_openDriver() returns 0`

cat /sys/kernel/debug/dri/0/amdgpu_pm_info return VCN:Enabled. That indicates Hardware decoding are working.

[Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00)]

Wasn't the whole thing fixed in Firefox 100 as a previous comment suggested? Was hoping so but I see the bug is still open.

[Aditya Suseno (aditya-suseno)]

My workaround:

Set media.ffmpeg.vaapi.enabled to FALSE

OR

Set media.rdd-process.enable to FALSE
While still having media.ffmpeg.vaapi.enabled set to TRUE

[Lxsq131 (lxsq131)]

(In reply to lxsq131 from comment #46)
> Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
> `MOZ_DISABLE_RDD_SANDBOX=0 firefox-trunk
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: VA-API version 1.8.0
> libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_1_8
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: va_openDriver() returns 0
> ATTENTION: default value of option mesa_glthread overridden by environment.
> ATTENTION: default value of option mesa_glthread overridden by environment.
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: VA-API version 1.8.0
> libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_1_8
> ATTENTION: default value of option mesa_glthread overridden by environment.
> libva info: va_openDriver() returns 0`
>
> cat /sys/kernel/debug/dri/0/amdgpu_pm_info return VCN:Enabled. That indicates Hardware decoding are working.

No. I tried again and the error was back. Still needs to disable RDD sandbox. Firefox Nightly 101.0a1 (2022-04-06).
```
libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/libdrm/amdgpu.ids: Permission denied
libva info: va_openDriver() returns 0
```

[Olivier Tilloy (osomon)]

This seems to be an upstream bug indeed: https://bugzilla.mozilla.org/show_bug.cgi?id=1751363

[W-jan-k (w-jan-k)]

*** Bug 1765824 has been marked as a duplicate of this bug. ***

[Stransky (stransky)]

*** Bug 1757791 has been marked as a duplicate of this bug. ***

[Mel34 (mel34)]

Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

[W-jan-k (w-jan-k)]

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.

[W-jan-k (w-jan-k)]

*** Bug 1766517 has been marked as a duplicate of this bug. ***

[Tempel-julian (tempel-julian)]

(In reply to Darkspirit from comment #52)
> I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.

It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load. For whatever weird reason, it very rarely can continue to show hardware decoding load, but then breaks upon next Firefox launch too. VAAPI is completely unusable since Firefox 99 with at least Intel, also with MOZ_DISABLE_RDD_SANDBOX=1. Reports that claim it to be working without making sure it really does so via intel_gpu_top over an extended period of usage (i.e. days) are unfortunately not reliable.

I think I'll just go back to 98 and perhaps set up some 3rd party sandboxing in case there are open CVEs. Hardware decoding is not a bonus on slow CPUs, it's a must. Really annoying that, despite of still being experimental, it has been broken so hard.

[Sonichedgehog-hyperblast00 (sonichedgehog-hyperblast00)]

In my case I use an AMD card on Manjaro Linux (default free amdgpu driver). I can say that with Firefox 99.0.1 video on Youtube usually plays but tries going back to a lower resolution at first, also any extra system load like other tabs will cause playback to freeze and you have to restart the video. MOZ_DISABLE_RDD_SANDBOX=1 still works fine for me thank goodness, using that it all functions as intended. Hope Firefox 100 at least doesn't break this workaround, in case the final fix isn't going to make it in time which would obviously be ideal.

[Stransky (stransky)]

(In reply to walmartguy from comment #54)
> (In reply to Darkspirit from comment #52)
> > I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> > Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.
>
> It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load.

That indicates a bud in decoding itself and not a sandbox issue. Please file that as a new bug.

[Distant Thunder (temptempor)]

Created attachment 9275655
firefox100_crash.log

Hello. Just to add in that this issue at least for my setup (Arch Linux, Firefox 100) is still current.

The previous comment suggest the problem might lie with the decoder but no other software on my machine has problem decoding through vaapi at the moment and the problems began right when RDD sandboxing was made default.

Firefox regularly fails and generate loads of crash log on my system each time it comes across a video since ~v98/99. The videos often crash, try to revert to low quality. It's particularly evident on sites like IMGUR. This was working fine before (and it took a long time to get it working) yet it was broken since 2 releases ago and is still in this state... It's quite sad Linux users are the second-class citizens on these features all over again.

---

Version: Firefox 100
OS: Arch Linux
FFMPEG: 5.0-7
vainfo: VA-API version: 1.14 (libva 2.14.0)

---
MOZ_DISABLE_RDD_SANDBOX=1 does not stop this failure on my machine.
Nor does MOZ_ENABLE_WAYLAND=1 individually, or combined.

---
Cf. Logs.

[agm97 (albertogomezmarin)]

for me at least the workaround is working as expected .. But I think it's something that has to be fixed as soon as possible.. the no use of vaapi gets a browser that is not smooth and freezes with almost every playback or preview...
firefox is a lot worse since 98 version in my opinion for that.
So I think the RDD sandbox has to be disabled until this is addressed. The day to day use is very bad

[Stransky (stransky)]

I think we can fix that by moving GL code out of RDD process. IIUC we need to implement DMABuf based gfx::SourceSurface which can be serialized over IPC bridge to parent/content process where GL can be used and we'll map dmabuf surface only when we're asked for surface data.

[Stransky (stransky)]

Another option may be EGL_MESA_platform_gbm extension which creates GL context over GBM device (the one we use for dmabuf). That may solve this problem too so investigating.

[Gpascutto (gpascutto)]

>Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.

>I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).

The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.

[Distant Thunder (temptempor)]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> >Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
>
> It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.
>
> >I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
>
> The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.

Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?

[Klubella (klubella)]

(In reply to temptempor from comment #62)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #61)
> > >Can you please clarify what does fix-optional status for firefox 100 mean for this bug?
> >
> > It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.
> >
> > >I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
> >
> > The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.
>
> Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?

For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)

[Miren Radia (m1ren)]

> For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)

What's your system configuration (e.g. OS, GPU, VAAPI library) and what flags have you manually changed in about:config? FWIW, mine is

OS: Ubuntu 20.04
GPU: Intel HD Graphics 630 (Kaby Lake)
VAAPI library: Tried `iHD` and `i965`

and have tried modifying numerous flags (always setting `media.ffmpeg.vaapi.enabled` to `true`) with the environment variable `MOZ_DISABLE_RDD_SANDBOX=1`.

[Stransky (stransky)]

If MOZ_DISABLE_RDD_SANDBOX does not work please file another bug - it's not a sandbox issue then. This bug is about sandbox so please don't add off topics comments here.
Thanks.

[Evilpies (evilpies)]

*** Bug 1771591 has been marked as a duplicate of this bug. ***

[W-jan-k (w-jan-k)]

As of bug 1770407, MOZ_DISABLE_RDD_SANDBOX=1 is no longer needed for Mesa users.

[W-jan-k (w-jan-k)]

*** Bug 1771632 has been marked as a duplicate of this bug. ***

[Urjryyhbnolzlvtrry (urjryyhbnolzlvtrry)]

Created attachment 9283237
firefox log

firefox does not use VAAPI (choppy video playback)
I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
Name Firefox
Version 102.0
Build ID 20220623063721
Distribution ID mozilla-flatpak

[Urjryyhbnolzlvtrry (urjryyhbnolzlvtrry)]

(In reply to urjryyhbnolzlvtrry from comment #69)
> Created attachment 9283237
> firefox log
>
> firefox does not use VAAPI (choppy video playback)
> I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
> Name Firefox
> Version 102.0
> Build ID 20220623063721
> Distribution ID mozilla-flatpak

Wayland enabled with MOZ_ENABLE_WAYLAND=1

[Gpascutto (gpascutto)]

This bug is closed because it was fixed, so you're seeing a different problem. Please file a new bug. Flatpak could be a factor here, note above there is another bug linked were specific fixes were needed for Snap too.

Edit: Your log shows VA-API successfully initializing, so this looks unrelated to RDD/sandboxing and may be a completely unrelated performance thing. Again, file a new bug specific to your problem.