Closed Bug 1384718 Opened 6 years ago Closed 6 years ago

WebGL doesn't initialize with Mesa 17.1 on Intel HD4600


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




Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed


(Reporter: TD-Linux, Assigned: TD-Linux)



(Keywords: regression, Whiteboard: sb+)


(4 files, 2 obsolete files)

Attached file about:support
Visiting the following site shows that WebGL is unavailable.

The console says:
Error: WebGL warning: Failed to create WebGL context: WebGL creation failed: * Error during native OpenGL init. * GL error 0x500 occurred during WebGL context initialization! * Exhausted GL driver options.

I suspect this was regressed by a Mesa update and not Nightly, though I have not tried bisecting yet.

I'm using Fedora 26 on Wayland (firefox in XWayland).
This is printed to stderr:

libGL error: MESA-LOADER: failed to retrieve device information
ATTENTION: default value of option force_s3tc_enable overridden by environment.
libGL error: Version 4 or later of flush extension not found
libGL error: failed to load driver: i915
libGL error: MESA-LOADER: failed to retrieve device information

It might be caused by sandboxing.
With security.sandbox.content.level = 1 it works, but with 2 it doesn't.
Component: Canvas: WebGL → Security: Process Sandboxing
Attachment #8890631 - Flags: review?(jld)
Note that there is one special case, the vmwgfx module when built standalone and not part of the kernel tree, which then uses a dynamic number. For this I don't know if it'd be better to make a more complex rule (that involves parsing /dev/dri/*) or to patch libdrm to not fail when reading these paths.
Comment on attachment 8890631 [details] [diff] [review]

Review of attachment 8890631 [details] [diff] [review]:

::: security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp
@@ +149,5 @@
>    // Bug 1312678: radeonsi/Intel with DRI when using WebGL
>    policy->AddDir(rdwr, "/dev/dri");
> +  // Bug 1384178: mesa driver loader
> +  policy->AddPrefix(rdonly, "/sys/dev/char/226:");

There's a separate block "Read permissions" below, please move this there.
Attachment #8890631 - Flags: review?(jld) → review+
Priority: -- → P2
Whiteboard: sb+
Target Milestone: --- → mozilla56
Attachment #8890631 - Attachment is obsolete: true
Keywords: checkin-needed
(In reply to Thomas Daede [:TD-Linux] from comment #8)
> Created attachment 8891113 [details] [diff] [review]
> 0001-Bug-1365789-Fix-typo-in-urlbar-background-color-for-.patch

This looks like it was meant for a different bug?
Flags: needinfo?(tdaede)
Keywords: checkin-needed
Attached file mesa-stuff.log
I ran into this bug while working on bug 1383888 (Mesa uses libudev and readlinkat(AT_FDCWD, ...)s the /sys/dev/char/226:* links), so I tried applying the patch from this bug, which made Mesa complain less, but there's still some "MESA-LOADER: could not get parent device".

gcp, you might want to look at this; there's… something going on with symlink reversal and .. normalization that seems to be not quite working like we expected it to.
Whoops sorry, grabbed the wrong patch.
Attachment #8891113 - Attachment is obsolete: true
Flags: needinfo?(tdaede)
Comment on attachment 8891130 [details] [diff] [review]

carried forward
Attachment #8891130 - Flags: review+
Assignee: nobody → tdaede
Keywords: checkin-needed
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #10)
> gcp, you might want to look at this; there's… something going on with
> symlink reversal and .. normalization that seems to be not quite working
> like we expected it to.

/sys/devices/pci0000:00/0000:00:0f.0/drm/card0 -> /sys/dev/char/226:0

I think what's happening is that the driver is trying to .. around in /sys/devices (which we don't allow). This is blocked, but after we see the block, we try symlink reversal to see if that ends up somewhere that we do allow, and that works *only* for the above file, which is the one actually white-listed, but not for anything else.

We might need to detect during policy formation what PCI device the GPU is and apply the whitelist to that in /sys/devices instead of /sys/dev/char/226:0.
Pushed by
Add sandbox rules for Mesa 17.1 driver loader. r=gcp
Keywords: checkin-needed
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.