Closed Bug 1712506 Opened 4 years ago Closed 3 years ago

Widevine try to access /proc/self/maps and /proc/net/unix

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 89
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox-esr91 94+ fixed
firefox92 --- wontfix
firefox93 --- fixed

People

(Reporter: corentin.poupry, Assigned: jld)

References

Details

Attachments

(1 file)

Bug 1712506 - In the Linux CDM sandbox, don't log when denying access to certain files.
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr91+
Details | Review

Everything worked fine so far.

The systemd log journal is flooded with lines looking like this:

mai 23 16:46:51 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps
mai 23 16:46:52 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps
mai 23 16:46:53 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps
mai 23 16:46:53 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/net/unix
mai 23 16:46:53 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/net/unix
mai 23 16:46:53 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/net/unix
mai 23 16:46:53 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps
mai 23 16:46:54 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps
mai 23 16:46:55 msi-arch plasmashell[23042]: Sandbox: attempt to open unexpected file /proc/self/maps

ps 23042 give the following:

    PID TTY      STAT   TIME COMMAND
  23042 ?        Sl     0:02 /usr/lib/firefox-developer-edition/plugin-container /home/helloedit/.mozilla/firefox/ba892pdc.dev-edition-default/gmp-widevinecdm/4.10.2209.1 22533 true gmplugin

This seems to indicate that the Widevine plugin is at fault.

Firefox Dev Edition : 89.0b14 (64 bits)

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Bryce, could you please help? Thanks!

Flags: needinfo?(bvandyk)

(In reply to Corentin Poupry from comment #0)

Everything worked fine so far.

To confirm, DRM playback is functioning despite the logs?

Looks like Widevine trying to probe memory regions and sockets. The memory probing seems likely to be part of its defensive mechanisms. I suspect the sockets are for a similar reason, though I have less insight into why.

Flags: needinfo?(bvandyk)

(In reply to Bryce Seager van Dyk (:bryce) from comment #3)

(In reply to Corentin Poupry from comment #0)

Everything worked fine so far.

To confirm, DRM playback is functioning despite the logs?

Looks like Widevine trying to probe memory regions and sockets. The memory probing seems likely to be part of its defensive mechanisms. I suspect the sockets are for a similar reason, though I have less insight into why.

Yes, the music is played and Spotify does not seem to be affected by this problem.

Thanks. So Widevine is attempting some checks, the sandbox is blocking those checks, but that is non-fatal for Widevine's functioning. However, it is resulting in log spam.

:jld, do you have any thoughts on this? Do you have any concerns about Widevine attempting these checks and/or our blocking?

Flags: needinfo?(jld)

I experience the same with https://netflix.com. I can watch Netflix, but the video seems to have micro lags and is not as smooth as usual.

but the video seems to have micro lags and is not as smooth as usual.

Please file a separate bug. The errors in the log are most likely inconsequential, we probably shouldn't be logging this except in debug/development builds. So if you see stutter that has to be investigated separately.

Seeing this on Fedora 34 as well, https://bugzilla.redhat.com/show_bug.cgi?id=1948331

It sounds as if we can just turn off this logging by default, by making it conditional on the SandboxInfo::kVerbose flag, which we do in some other cases where we expect them to happen in normal operation. (It could also be conditional on build type, but we might want to have it available on release builds for troubleshooting. Another possibility would be adding items to the SandboxOpenedFiles object which don't have fds but just indicate that opens are expected to fail, to suppress logging for just these paths; however, that's more work and it's not clear that it would be useful.)

I hope we don't need to allow these paths for a later CDM version: both of them have privacy implications, especially the amount of global state visible in /proc/net/unix.

Flags: needinfo?(jld)
Severity: -- → S3
Priority: -- → P3
Status: UNCONFIRMED → NEW
Ever confirmed: true

I confirm the problem with Firefox 90 running Linux "5.4.0-77-generic #86~18.04.1-Ubuntu SMP Fri Jun 18 01:23:22 UTC 2021 x86_64" while playing https://open.spotify.com. Also sporadic video failure (non fatal) is happen since Firefox 90.

(In reply to marciowb from comment #12)

I confirm the problem with Firefox 90 running Linux "5.4.0-77-generic #86~18.04.1-Ubuntu SMP Fri Jun 18 01:23:22 UTC 2021 x86_64" while playing https://open.spotify.com. Also sporadic video failure (non fatal) is happen since Firefox 90.

Could you create another bug for the video failure and describe the symptoms there? That sounds like a different problem that could be investigated separately.

Hello, I'm on Debian Bullseye (stable). I have the same issue when watching NetFlix content with Firefox 78.13.0, Widevine media.gmp-widevinecdm.version 4.10.2209.1 (I use the Firefox version privded by Bullseye).

The warning disappears as soon as I close the netflix tab.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #9)

Another possibility would be adding items to the SandboxOpenedFiles object which don't have fds but just indicate that opens are expected to fail, to suppress logging for just these paths; however, that's more work and it's not clear that it would be useful.)

It's actually not much work, because we already have a “return error and don't log” path for files that we fail to pre-open (e.g., if they don't exist). I have a patch. And it is somewhat useful, because these log messages (for different files) made it easier to analyze bug 1725828.

Assignee: nobody → jld

The Widevine CDM tries to open certain procfs/sysfs files, as noted
in the bug, but doesn't appear to need them; some of them are opened
repeatedly, causing log spam. This patch suppresses logging for the
files where this is known to happen, by adding "opened file" objects
that always silently fail.

It would also be possible to turn off all of this logging by default
and make it conditional on MOZ_SANDBOX_LOGGING, but it's relatively
low-noise (compared to content process file access) and provides some
value (see bug 1725828), so for now let's leave it enabled and just
blocklist a few files.

Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ab80197101b9 In the Linux CDM sandbox, don't log when denying access to certain files. r=gcp

https://hg.mozilla.org/mozilla-central/rev/ab80197101b9

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox93: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch

Still seeing this on Linux Mint using Firefox 92.0.1

xsessions-errors file grows to 500 to 600k in a short time with repeats of

Sandbox: attempt to open unexpected file /proc/net/unix
Sandbox: attempt to open unexpected file /proc/self/maps

I suspect it's logging so much it is slowing down video in Netflix and Disney streaming services.

Too late to fix this in Fx92 or 91.2esr, but we can get this in 91.3esr next cycle. Feel free to nominate for ESR91 approval.

status-firefox92: affected → wontfix
status-firefox-esr91: ? → affected
tracking-firefox-esr91: --- → 94+
Flags: needinfo?(jld)

Comment on attachment 9237870 [details]
Bug 1712506 - In the Linux CDM sandbox, don't log when denying access to certain files.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: The bug is mostly cosmetic and not directly visible in normal use, but there's at least one report of performance impact (comment #6) which could be related, and the patch is relatively low risk.
  • User impact if declined: See above; potentially less smooth video playback (not confirmed).
  • Fix Landed on Version: 93
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch uses the existing case for when a file we allowlisted doesn't exist (except that in this case the files do exist); it doesn't modify the pathname matching code, and it doesn't expose any additional resources to the sandboxed process.
  • String or UUID changes made by this patch: none
Flags: needinfo?(jld)
Attachment #9237870 - Flags: approval-mozilla-esr91?

Comment on attachment 9237870 [details]
Bug 1712506 - In the Linux CDM sandbox, don't log when denying access to certain files.

Approved for 91.3esr.

Attachment #9237870 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

This appears to continue to affect the 100.0.2nd version:

PS /> firefox
Gtk-Message: 00:19:44.796: Failed to load module "appmenu-gtk-module"
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.
ATTENTION: default value of option mesa_glthread overridden by environment.
Sandbox: attempt to open unexpected file /sys/devices/system/cpu/cpu0/cache/index2/size
Sandbox: attempt to open unexpected file /sys/devices/system/cpu/cpu0/cache/index3/size
Sandbox: attempt to open unexpected file /sys/devices/system/cpu/present
Sandbox: attempt to open unexpected file /sys/devices/system/cpu/possible

However, the tab that was initially loaded was "http://pixiv.net", which I expect does not utilize digital rights-management.

which I expect does not utilize digital rights-management.

So it won't be using Widevine, so there's no relation to this bug.

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

Attachment

General

Creator:
Created:
Updated:
Size: