Crash in [@ semget]: Don't allow VAAPI in the content process / require RDD for VAAPI
Categories
(Core :: Security: Process Sandboxing, defect, P1)
Tracking
()
People
(Reporter: jan, Assigned: jld)
References
(Blocks 2 open bugs)
Details
(Keywords: crash, nightly-community)
Crash Data
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
(Darkspirit from bug 1743638 comment #1)
bp-14b66965-1dbb-4408-b431-9369f0211130 30.11.21, 01:26 [@ mozilla::VideoFrameSurfaceVAAPI::ReleaseVAAPIData ]
bp-b2b09184-19c1-40de-b2a5-9c4fc0211130 30.11.21, 01:26 [@ semget ]
VAAPI crashed in the RDD process (bug 1743638) and then it was apparently tried in the content process and failed there:
This seems to be the original crash from bug 1619585 which occurs in the content process.
https://hg.mozilla.org/integration/autoland/rev/669ca27af67f
Previously there was a !XRE_IsRDDProcess() check. Can such a check be re-added, but require RDD this time?
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
I assume restricting VAAPI to the RDD process would also be desirable for security:
Users who have manually disabled the RDD process or even the sandbox would be forced to reset some prefs back to their defaults if they want to keep using VAAPI.
https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
(In reply to Darkspirit from comment #1)
I assume restricting VAAPI to the RDD process would also be desirable for security:
Users who have manually disabled the RDD process or even the sandbox would be forced to reset some prefs back to their defaults if they want to keep using VAAPI.
https://wiki.archlinux.org/title/Firefox#Hardware_video_acceleration
Please also consider
-
disallowing VAAPI if a non-Nightly build has security.sandbox.content.level=0 or MOZ_DISABLE_RDD_SANDBOX=1, so that the Arch Wiki would have to suggest opposite settings (= re-enabling RDD+sandboxes) to Firefox >=96 users.
-
printing a warning on all channels if media.ffmpeg.vaapi.enabled is true but other recommended conditions are not met to make sure users come back to a supported and more secure configuration:
e.g.
if media.ffmpeg.vaapi.enabled==true && (!XRE_IsRDDProcess() || security.sandbox.content.level == 0 || MOZ_DISABLE_RDD_SANDBOX == 1)WARNING: You have enabled VAAPI, but it won't properly work unless the following conditions are met: - open about:config, set RDD prefs and security.sandbox.content.level back to their defaults - set media.rdd-ffmpeg.enabled to true for H264 - the MOZ_DISABLE_RDD_SANDBOX environment variable must not be set
If not here, I'll file a separate bug.
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
The content process sandbox won't necessarily work with VA-API drivers
(e.g., Intel if it uses SysV IPC), and in general we'd like to remove
direct access to the window system / GPU / etc. Therefore, this patch
restricts VA-API use to the RDD process, where it is intended to work
(with sandboxing enabled).
Comment 4•3 years ago
|
||
The severity field is not set for this bug.
:gcp, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Description
•