815437 - Graphics driver block request: All AMD devices on all Mac OSX versions >= 10.6 for WebGL anti-aliasing

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

Compare bug 809550 where we did the same for NVIDIA and Intel.

Please add 3 new blocklist entries:

OS: Darwin 10, Darwin 11, Darwin 12
Vendor: 0x1002
Feature: WEBGL_MSAA
Feature status: BLOCKED_DEVICE

Reason: same as in bug 809550. Was shown to affect AMD GPUs as well, after all, by Chrome security researchers. See https://code.google.com/p/chromium/issues/detail?id=162466

Here, 0x1002 is the vendor ID for AMD. Darwin 10 is Mac OS 10.6, 11 is 10.7, 12 is 10.8. More details can be found in bug 809550.

There also is a testcase for WebGL anti-aliasing blocklisting here:
http://people.mozilla.org/~bjacob/msaatest.html
 (See bug 809550 comment 7)

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

No need for this to be a security bug after all (Chrome bug is public).

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

Also, note that with that, we'll be blacklisting WebGL anti-aliasing on _all_ drivers on Mac, so you are welcome to instead go for a unified blacklist entry (well, one for each Mac OS version) that is not specific to a particular GPU vendor. I *think* that should work and have the desired effect of applying regardless of the vendor.

Jorge: assigning to you if that's OK.

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

The blocks are staged now:
219 for Darwin 10
221 for Darwin 11
223 for Darwin 12

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Thanks!

Comment 5

[u279076]

I'm not aware if QA (or our contractors) have ATI hardware running OSX 10.6, 10.7, and 10.8. It's going to take me some time to track down this hardware, assuming that we have it.

If this is a priority, we might need to consider pushing untested or tested outside of QA.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

This is a security emergency, so please push even without QA. Though QA would be very useful of course.

Comment 7

[u279076]

Security emergency or not, we should make an attempt to at least spotcheck this before it goes live. A security emergency begs thoroughness.

I've emailed QA employees and contractors to try to track down hardware. We can spotcheck if/when we find something. Benoit, is there anyone in Engineering with hardware that could test this?

If we can't secure testing before the end of the day, I would advise Release Management to make a judgement call.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #7)
> Security emergency or not, we should make an attempt to at least spotcheck
> this before it goes live. A security emergency begs thoroughness.
> 
> I've emailed QA employees and contractors to try to track down hardware. We
> can spotcheck if/when we find something. Benoit, is there anyone in
> Engineering with hardware that could test this?

We do have macs with AMD (== ATI) graphics, as that includes most Macs sold circa 2011. But people are busy with B2G at the moment, so I don't know if it's reasonable to ask them to take a break from that.

Comment 9

[u279076]

Taking 5 minutes to spotcheck a Desktop (our bread and butter) security emergency takes precedence over B2G IMO.

Comment 10

[u279076]

Juan is going to test OSX 10.8 for us. Tyler Downer is looking for other people to help as well.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

OK, I have a Mac with ATI graphics here. Please remind me how I can get the blocklist to test?

Comment 12

[u279076]

Instructions I sent to Juan, verbatim:

1. Start Firefox with a new profile and load http://people.mozilla.org/~bjacob/msaatest.html
> You should see something like https://wiki.mozilla.org/File:Msaatest_screenshot.png
>> "AVAILABLE" and the two different test images
2. Change "addons.mozilla.org" to "addons-dev.allizom.org" in extensions.blocklist.url in about:config
3. Restart Firefox
4. Open the error console and force a blocklist ping by pasting the following into the textbox and clicking eval
> Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsITimerCallback).notify(null);
5. Wait a minute and restart Firefox again
6. Load http://people.mozilla.org/~bjacob/msaatest.html
> You should see something like https://wiki.mozilla.org/File:Msaatest_screenshot.png
>> "UNAVAILABLE" and two identical test images

I will need this tested with Firefox Nightly 20.0a1, Aurora 19.0a2, 18.0b2, 17.0.1, and 17.0.1esr.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

Thanks! I confirm that all works as expected for me on a mid-2011 macbook pro with AMD graphics.

before: antialiasing AVAILABLE
after: antialiasing UNAVAILABLE

Comment 14

[u279076]

(In reply to Benoit Jacob [:bjacob] from comment #13)
> Thanks! I confirm that all works as expected for me on a mid-2011 macbook
> pro with AMD graphics.
> 
> before: antialiasing AVAILABLE
> after: antialiasing UNAVAILABLE

Which OS version?

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> Which OS version?

Mac OS 10.8.

Comment 16

[juan becerra [:juanb]]

Attachment: about support using fresh profile and fresh nightly installation

When I go through the instructions in comment #12 using the latest Nightly, on a new profile, and what I see in step 1 is:

"The WebGL implementation reports that WebGL antialiasing is
UNAVAILABLE"

I'm attaching my about:support information.

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

Yep, that's OK, we were already blacklisting anti-aliasing on some AMD cards on Mac. Seems like you got one of those. So you won't be able to use that machine to verify this bug on this Mac.

Comment 18

[u279076]

Tyler wasn't able to find any testers. Benoit, given this is a security issue I think we should probably push this live based on your testing. I'm not confident that we'll get much more testing done before the end of the day.

I'm ccing Lukas from Release Management to evaluate the risk and make a call on that.

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #18)
> Tyler wasn't able to find any testers. Benoit, given this is a security
> issue I think we should probably push this live based on your testing. I'm
> not confident that we'll get much more testing done before the end of the
> day.

I agree with this - let's not wait on more testing, we have the one confirmation and should continue to try and get confirmation on 10.7/10.6 but not hold pushing this.

Comment 20

[Jorge Villalobos [:jorgev] (he/him)]

Done.

230 for Darwin 10
232 for Darwin 11
234 for Darwin 12

Comment 21

[u279076]

Benoit, can you please check that this works in production now? The test is the same as comment 12 except you can ignore step 2 and 3.