Closed Bug 1751363 Opened 2 years ago Closed 2 years ago

VA-API: creating video snapshot fails due to RDD sandbox + Since bug 1724385 (98), VAAPI fails in general due to RDD sandbox

Categories

(Core :: Security: Process Sandboxing, defect, P1)

Product:
Core
Component:
Security: Process Sandboxing
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox96 --- disabled
firefox97 --- disabled
firefox98 --- disabled
firefox99 --- disabled
firefox100 --- disabled
firefox101 --- disabled
firefox102 --- fixed

People

(Reporter: stransky, Assigned: jld)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

firefox100_crash.log
759.61 KB, text/x-log
Details
firefox log
1.09 MB, application/octet-stream
Details

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

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.

Dupe of bug 1749623?

See Also: → 1749623
No longer blocks: egl-linux-vaapi
Severity: -- → S3
Priority: -- → P3

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 --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'

status-firefox96: --- → disabled
status-firefox97: --- → disabled
status-firefox98: --- → disabled
status-firefox-esr91: --- → unaffected
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
See Also: → 1751709
Summary: VA-API: creating video snapshot fails due to RDD sandbox → VA-API: creating video snapshot fails due to RDD sandbox + Since bug 1724385 (98), VAAPI fails in general due to RDD sandbox
No longer blocks: 1724385
Regressed by: 1724385

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

status-firefox99: --- → affected

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

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.

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.

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.

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.

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.

Flags: needinfo?(gpascutto)

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

The feature is marked as disabled in Firefox 98.

Flags: needinfo?(gpascutto) → needinfo?(stransky)

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.

Flags: needinfo?(stransky)

(In reply to sonichedgehog_hyperblast00@yahoo.com 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.

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.

Assignee: nobody → jld
Priority: P3 → P1

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

See Also: 1749623 →

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

Flags: needinfo?(dsmith)

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.

status-firefox100: fix-optional → disabled
status-firefox101: affected → disabled
Flags: needinfo?(dsmith)

(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.

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.

(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.

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.

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.

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.

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.

Depends on: 1770520

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

Status: NEW → RESOLVED
Closed: 2 years ago
status-firefox102: --- → fixed
Depends on: 1770407
No longer depends on: 1770520
Resolution: --- → FIXED
Depends on: 1772142
Attached file 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

(In reply to urjryyhbnolzlvtrry from comment #69)

Created attachment 9283237 [details]
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

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: