Closed Bug 1743647 Opened 2 years ago Closed 2 years ago

Crash in [@ semget]: Don't allow VAAPI in the content process / require RDD for VAAPI

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
97 Branch
Tracking Status
firefox-esr91 --- disabled
firefox95 --- disabled
firefox96 --- disabled
firefox97 --- fixed

People

(Reporter: jan, Assigned: jld)

References

(Blocks 1 open bug)

Details

(Keywords: crash, nightly-community)

Crash Data

Attachments

(1 file)

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

Crash Signature: [@ semget]

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

Type: task → defect
Component: Audio/Video: Playback → Security: Process Sandboxing
Assignee: nobody → jld

(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

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

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

See Also: → 1744037
Blocks: 1678233

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

The severity field is not set for this bug.
:gcp, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gpascutto)
Severity: -- → S2
Flags: needinfo?(gpascutto)
Priority: -- → P1
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f3aeef706002
Allow VA-API only in the RDD process. r=alwu
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Crash Signature: [@ semget] → [@ semget] [@ @0x0 | MmdDevice::CreateFactory] [@ @0x0 | iHD_drv_video.so@0x4fcbbe ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: