1356038 - widevine plugin not loading in sandbox

Status: UNCONFIRMED

(Core :: Audio/Video: GMP, defect, P5)

Description

[Morgane ”Sardem FF7” Glidic]

Trying to read a Netflix video, it fails to load the Wideviwe plugin.

In the log, you can see:

Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/nightly/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
Sandbox: attempt to open file /etc/ld-x86_64-pc-linux-gnu.cache (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so

###!!! [Parent][MessageChannel::Call] Error: Channel error: cannot send/recv


I tried a naive symlink of libgcc_s.so.1 in /usr/x86_64-pc-linux-gnu/lib/nightly but it didn’t work.

I build nightly on my own (via our package manager at Exherbo, Paludis). Here are the options:
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-application=browser --disable-tests PKG_CONFIG=x86_64-pc-linux-gnu-pkg-config CC=x86_64-pc-linux-gnu-cc LD=x86_64-pc-linux-gnu-ld CXX=x86_64-pc-linux-gnu-c++ --disable-debug-symbols --enable-system-ffi --enable-default-toolkit=cairo-gtk3 --enable-system-hunspell --disable-crashreporter --enable-dbus --disable-elf-hack --enable-extensions=default --disable-gconf --enable-gio --disable-install-strip --enable-necko-wifi --enable-optimize=-O2 --enable-pulseaudio --enable-raw --enable-safe-browsing --disable-startup-notification --disable-strip --enable-system-pixman --disable-updater --prefix=/usr/x86_64-pc-linux-gnu --with-branding=browser/branding/nightly --with-default-mozilla-five-home=/usr/x86_64-pc-linux-gnu/lib/nightly --with-distribution-id=org.exherbo --with-system-bz2 --with-system-jpeg --with-system-libevent=/usr/x86_64-pc-linux-gnu --with-system-libvpx --with-system-zlib --x-includes=/usr/x86_64-pc-linux-gnu/include --x-libraries=/usr/x86_64-pc-linux-gnu/lib

For whatever reason, I have to set LD_LIBRARY_PATH to /usr/x86_64-pc-linux-gnu/lib/nightly for nightly to run, otherwise it fails with "libmozsandbox.so: cannot open shared object file: No such file or directory"

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Sounds like a sandboxing issue, so redirecting to Jed.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

>For whatever reason, I have to set LD_LIBRARY_PATH to /usr/x86_64-pc-linux-gnu/lib/nightly for nightly to run

Not totally familiar with the media sandbox, but it seems very likely that your "workaround" is exactly what caused this problem, given that the sandboxing failure is trying to open this file (which likely doesn't exist):

/usr/x86_64-pc-linux-gnu/lib/nightly/libgcc_s.so.1

>otherwise it fails with "libmozsandbox.so: cannot open shared object file: No such file or directory"

libmozsandbox is probably the first shared library we try to open. So I'm not convinced these failures actually have anything to do with sandboxing at all.

Are you building correctly? ./mach build and then either 

./mach run 

or 

./mach dist (to get a standalone package).

Comment 3

[Morgane ”Sardem FF7” Glidic]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> >For whatever reason, I have to set LD_LIBRARY_PATH to /usr/x86_64-pc-linux-gnu/lib/nightly for nightly to run
> 
> Not totally familiar with the media sandbox, but it seems very likely that
> your "workaround" is exactly what caused this problem, given that the
> sandboxing failure is trying to open this file (which likely doesn't exist):
> 
> /usr/x86_64-pc-linux-gnu/lib/nightly/libgcc_s.so.1

Actually, not all builds require LD_LIBRARY_PATH, not sure what triggers that need.
The build I’m on currently doesn’t need it, but fails all the same.


Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/nightly/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
Sandbox: attempt to open file /etc/ld-x86_64-pc-linux-gnu.cache (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/sardemff7/.mozilla/firefox/sardemff7/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so

> >otherwise it fails with "libmozsandbox.so: cannot open shared object file: No such file or directory"
> 
> libmozsandbox is probably the first shared library we try to open. So I'm
> not convinced these failures actually have anything to do with sandboxing at
> all.

What triggers the sandboxing-related issue to me is that the sandbox cannot load a files that actually exists: /usr/x86_64-pc-linux-gnu/lib/libgcc_s.so.1 (though it’s a symlink to allow parallel-installation of multiple versions, the real file is /usr/x86_64-pc-linux-gnu/lib/libgcc_s-6.so.1).

> Are you building correctly? ./mach build and then either 
> 
> ./mach run 
> 
> or 
> 
> ./mach dist (to get a standalone package).

I build using my package manager and we have a fairly specific setup (no unprefixed toolchain, /usr/x86_64-pc-linux-gnu prefix). The commands run to build are listed here: https://git.sardemff7.net/exherbo/sardemff7-pending/tree/exlibs/mozilla-app.exlib and I have a few patches on top of tip: https://git.sardemff7.net/exherbo/sardemff7-pending/tree/packages/net-www/nightly/files
That’s a fair bit of sed patching, but it would probably require too much time to understand the build system enough to make a real patch to support our setup, so I decided to go the workaround way.

I think I tried to use ./mach build some time ago and it failed, but I can try again if there’s any chance it could help.

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The way this is supposed to work is that the plugin's library dependencies are a subset of Firefox's, so dlopen() makes exactly one open() call, for the plugin file itself.  That open() never actually happens, because the seccomp-bpf policy doesn't allow open(), but the SIGSYS handler changes the register state to return a file descriptor we opened earlier.

This might be going wrong if Firefox is being built with static libgcc.  I don't know if we support that, or if we even have a position either way on supporting it, or what would happen if we just always passed -shared-libgcc when linking.


As for LD_LIBRARY_PATH, it shouldn't need to be set manually.  For child processes it's set (in ipc/glue/GeckoChildProcessHost.cpp) to the directory containing the main executable.  The main process is a little different; if I'm following the code in nsXPCOMGlue.cpp correctly, it reads a file named dependentlibs.list (in the directory with the executable) and loads each library listed there (from that same directory) with RTLD_GLOBAL, so that library path search won't be needed.

Comment 5

[Ian Stakenvicius]

So Gentoo linux is seeing this on mozilla-53.0 ..  We're not doing anything to the environment, nor are we doing any sort of system library copying or symlinking at all; in fact we're doing the same thing as we've been doing for 52.x and previous (where it works).

Unfortunately I didn't build with debug symbols enabled, so the stack trace isn't overly useful, but it shows a similar pattern to the above.  libc.so.6 is from glibc-2.23 if it matters.

Sandbox: seccomp sandbox violation: pid 11746, syscall 28, args 140229876908032 2097152 15 1612 140229879005520 0.  Killing process.
Sandbox: crash reporter is disabled (or failed); trying stack trace:
Sandbox: frame #01: madvise[/lib64/libc.so.6 +0xe37d7]
Sandbox: frame #02: ???[/usr/lib64/firefox/plugin-container +0x2a0f9]
Sandbox: frame #03: ???[/usr/lib64/firefox/plugin-container +0x1f872]
Sandbox: frame #04: ???[/usr/lib64/firefox/plugin-container +0x1e5ba]
Sandbox: frame #05: ???[/usr/lib64/firefox/plugin-container +0x203e9]
Sandbox: frame #06: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x16ef38]
Sandbox: frame #07: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x16f2bf]
Sandbox: frame #08: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x25a5ec]
Sandbox: frame #09: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x25cc03]
Sandbox: frame #10: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x25e14b]
Sandbox: frame #11: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x15c040]
Sandbox: frame #12: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x15bb16]
Sandbox: frame #13: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x15b97d]
Sandbox: frame #14: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x5236e]
Sandbox: frame #15: ???[/home/me/.mozilla/firefox/4q3cgsfy.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so +0x520f4]
Sandbox: frame #16: ???[/usr/lib64/firefox/libxul.so +0x19d85ed]
Sandbox: frame #17: ???[/usr/lib64/firefox/libxul.so +0x19cbc51]
Sandbox: frame #18: ???[/usr/lib64/firefox/libxul.so +0xc72139]
Sandbox: frame #19: ???[/usr/lib64/firefox/libxul.so +0xc5e8c5]
Sandbox: frame #20: ???[/usr/lib64/firefox/libxul.so +0xc17ea8]
Sandbox: frame #21: ???[/usr/lib64/firefox/libxul.so +0xc1e70a]
Sandbox: frame #22: ???[/usr/lib64/firefox/libxul.so +0xc1f6fc]
Sandbox: frame #23: ???[/usr/lib64/firefox/libxul.so +0xc1f84d]
Sandbox: frame #24: ???[/usr/lib64/firefox/libxul.so +0xc015b5]
Sandbox: frame #25: ???[/usr/lib64/firefox/libxul.so +0xc04157]
Sandbox: frame #26: ???[/usr/lib64/firefox/libxul.so +0xc042ef]
Sandbox: frame #27: ???[/usr/lib64/firefox/libxul.so +0xbff35b]
Sandbox: frame #28: ???[/usr/lib64/firefox/libxul.so +0xbff28a]
Sandbox: frame #29: ???[/usr/lib64/firefox/libxul.so +0x23f5cb7]
Sandbox: frame #30: ???[/usr/lib64/firefox/plugin-container +0x7001]
Sandbox: frame #31: ???[/usr/lib64/firefox/plugin-container +0x6cd7]
Sandbox: frame #32: __libc_start_main[/lib64/libc.so.6 +0x20790]
Sandbox: frame #33: _start[/usr/lib64/firefox/plugin-container +0x6e99]
Sandbox: frame #34: ??? (???:???)
Sandbox: end of stack.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Ian Stakenvicius from comment #5)
> Sandbox: seccomp sandbox violation: pid 11746, syscall 28, args
> 140229876908032 2097152 15 1612 140229879005520 0.  Killing process.
> Sandbox: crash reporter is disabled (or failed); trying stack trace:
> Sandbox: frame #01: madvise[/lib64/libc.so.6 +0xe37d7]

This is bug 1364533.

Comment 7

[Jakob Nixdorf]

I just tried to use widevine with the stable version of firefox (54) in Exherbo Linux (same distro @Sardem FF7, who reported this bug, uses).
I don't have to do anything with LD_LIBRARY_PATH for firefox to run and still get the same error:

> Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/firefox/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/flocke/.mozilla/firefox/kjiycn4f.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
> Sandbox: attempt to open file /etc/ld-x86_64-pc-linux-gnu.cache (flags=02000000) which is not the media plugin /home/flocke/.mozilla/firefox/kjiycn4f.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
> Sandbox: attempt to open file /usr/x86_64-pc-linux-gnu/lib/libgcc_s.so.1 (flags=02000000) which is not the media plugin /home/flocke/.mozilla/firefox/kjiycn4f.default/gmp-widevinecdm/1.4.8.903/libwidevinecdm.so
> 
> ###!!! [Parent][MessageChannel::Call] Error: Channel error: cannot send/recv

When trying with MOZ_DISABLE_GMP_SANDBOX=1 then everything works fine.

In case it helps, here are the shared libs libwidevinecdm.so is linked agaist:

> [flocke@toybox 1.4.8.903]# ldd libwidevinecdm.so
>         linux-vdso.so.1 (0x00007ffe3d3ec000)
>         libm.so.6 => /usr/x86_64-pc-linux-gnu/lib/libm.so.6 (0x00007f0c7efce000)
>         libstdc++.so.6 => /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 (0x00007f0c7ec45000)
>         libgcc_s.so.1 => /usr/x86_64-pc-linux-gnu/lib/libgcc_s.so.1 (0x00007f0c7ea2e000)
>         libpthread.so.0 => /usr/x86_64-pc-linux-gnu/lib/libpthread.so.0 (0x00007f0c7e810000)
>         libc.so.6 => /usr/x86_64-pc-linux-gnu/lib/libc.so.6 (0x00007f0c7e46a000)
>         /usr/x86_64-pc-linux-gnu/lib64/ld-linux-x86-64.so.2 (0x0000557968682000)

This is the side I used to check if widevine is working: https://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2018.html?test_type=encryptedmedia-test&timestamp=1498295164348

Any news on this bug? I'm happy to provide more information and test patches/fixes, I would really like to be finally able to watch Netflix on my Linux box ;)

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Based on commment 4, this might be due to the build configuration used by that distro. Do the official binaries (from Mozilla's site, not Exherbo) work?

Comment 9

[Jakob Nixdorf]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)
> Based on commment 4, this might be due to the build configuration used by
> that distro. Do the official binaries (from Mozilla's site, not Exherbo)
> work?

Yes, I just tested to official binaries and they work.
Any idea where in the build the problem could be?
As SardemFF7 already said we have a very specific build system which supports native cross-compiling.
All architecture-specific binaries and libraries are stored under /usr/x86_64-pc-linux-gnu/{bin,lib} (for x86_64 system obviously) and not under /usr/{bin,lib} like in the most cases.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

>Any idea where in the build the problem could be?

As stated in comment 4: "This might be going wrong if Firefox is being built with static libgcc."

Comment 11

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Let's not try to fix this.

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

For what it's worth, distros that use static libgcc can fix this locally by patching the source to do something like `Unused << dlopen("libgcc_s.so.1", RTLD_GLOBAL|RTLD_LAZY);` in SetMediaPluginSandbox — preferably after making sure that the use of static libgcc is intentional and not just an oversight in the distro's toolchain configuration.

Comment 13

[Purva Weaves]

https://www.purvaweaves.info/