1421944 - Webrtc microphone input broken in Windows Insider Preview Build 17046

Status: RESOLVED WORKSFORME

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

Description

[samlh]

Attachment: debug log.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171129220149

Steps to reproduce:

Install Windows Insider Preview build 17046
Install and run Firefox
Open https://mozilla.github.io/webrtc-landing/gum_test.html
Click audio
Allow access to the microphone


Actual results:

Can hear the microphone input, and the time on the media player increases


Expected results:

Opt: Cannot hear microphone input, time does not increase

Debug: tab crashes - see attached log

Comment 1

[samlh]

Attachment: opt log.txt

Comment 2

[Alex Chronopoulos [:achronop]]

I see the failure in the logs:

2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1646: (000001EEEC95DA60) Setup capture: device=000001EE80EB30B0
2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1587: Setup requested=[f=2 r=48000 c=1 l=undefined] mix=[f=2 r=48000 c=1 l=mono]
2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1597: Unable to initialize audio client for capture: 80070005.

Comment 3

[samlh]

I just faffed around with mozregression, and I cannot find a good build (checked back to early 2016). Also, disabling sandboxing works around the failure.

Comment 4

[Alex Chronopoulos [:achronop]]

That makes sense because error 0x80070005 is E_ACCESSDENIED - General access denied error. I will pass it on sandbox to tell us what they think. 

P.S. bug 1418694 in "See also" is a different case, it may be better to remove it in order to avoid any confusion.

Comment 5

[Jim Mathies [:jimm]]

ni to david for some investigation.

Comment 7

[Nils Ohlmeier [:drno]]

In bug 1422971 I also noted that it works fine for me with Fx 57 as long as e10s is off. Once e10s is on mic access no longer works. Probably the sandbox for the content process is different/stricter?!

Comment 8

[Paul Adenot (:padenot)]

There is no sandbox when e10s is off.

Comment 9

[Jim Mathies [:jimm]]

Cubeb remoting on Windows should solve this. We can always hack a work around if that code isn't ready and this bug shows up in a release version of Windows.

Comment 10

[Nils Ohlmeier [:drno]]

(In reply to Jim Mathies [:jimm] from comment #9)
> Cubeb remoting on Windows should solve this.

What is the bug number for that?
How far are we from landing this? And can it get uplifted to release (see below)?

> We can always hack a work
> around if that code isn't ready and this bug shows up in a release version
> of Windows.

This is not very well explained in this bug, but over in the bug 1422971 I explained that this change in Windows affects also current release.

My current assumption (= worst case scenario) is that Microsoft as some point in the near term future will make Preview Build 17046 the next Win 10  update and at that point all Firefox users who have e10s turned on will loose access to their microphones. From my point of view that would be a pretty catastrophic regression for gUM/WebRTC.

To prevent that regression from happening I see the following options:
#1) somehow contact Microsoft and ask them to revert what ever change in Win 10 Preview Build 17046 causes this problem
#2) try to adjust the Firefox sandbox to the change in Win 10 Preview Build 17046 and uplift that change to Fx release
#3) turn off Firefox sandbox via user prefs (not sure if that's possible) if worst comes to worst
... probably I'm missing other/more options here. 

But looking at the above I don't think that waiting for "Cubeb remoting on Windows" to land is an acceptable solution to the problem.

Comment 11

[Bob Owen (:bobowen) PTO until 13th Aug]

handyman - I spoke to padenot and he said that it is [1] that is failing, so it doesn't appear to be the same issue as we once had for NPAPI (which makes sense because that fix has already been implemented for cubeb as we discussed). 

[1] https://hg.mozilla.org/mozilla-central/file/f1329009bf0da7b40229ea75ffe18f201b71359e/media/libcubeb/src/cubeb_wasapi.cpp#l1606

Comment 12

[David Parks [:handyman]]

Yeah, this is more complex than I initially thought.  I don't have a solution in mind yet but here is a brain dump:

* I was initially misled by the other E_ACCESSDENIED error in the attached debug log.  Its probably not relevant but there is a "Setup render" (audio output) request that fails before the "Setup capture" (mic input) request that is this bug.  The failure is in the device enumeration, as it was in Flash [1].

> 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1679: (000001EEEC95DA60) Setup render: device=0000000000000000
> 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1587: Setup requested=[f=2 r=48000 c=2 l=undefined] mix=[f=2 r=48000 c=2 l=stereo]
> [...]
> 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1013: Could not register endpoint notification callback: 80070005
> 2017-11-30T01:16:17: INFO : [CubebOperation #1]: E/cubeb z:/build/build/src/media/libcubeb/src/cubeb_wasapi.cpp:1866: failed to register notification client, 80070005

* The IMMDevice::Initialize command fails for the mic but succeeds for the aforementioned output device.  This suggests that the system is distinguishing between them, which means that it may not be easily finessed.  But since we are dealing with a new one-OS-version issue, finesse is still on the table.  In particular, IMMDevice::Initialize may be failing but there are other ways to get at a IAudioClient object that _could_ succeed [2].  We could use IMMDeviceEnumerator::GetDevice [3] -- if we had the device name -- which we are probably blocked from since its the same API that causes the render setup above to fail.  However, we can very easily get that name from the parent process.  Something to try.

* If MS is honestly blocking access to the device and don't agree to revert that then we are in some trouble.  I can look into what it is about the sandbox that breaks this but samlh's statement that "I just faffed around with mozregression, and I cannot find a good build (checked back to early 2016)" is discouraging.  Some kind of aggressive remoting of behavior would be warranted (if possible) over dialing the sandbox back that far.

------
[1] https://searchfox.org/mozilla-central/rev/ff462a7f6b4dd3c3fdc53c9bc0b328f42a5b3d2b/dom/plugins/ipc/PluginUtilsWin.cpp#50
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd370865(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/dd371402(v=vs.85).aspx

Comment 13

[Matthew van Eerde]

Hi, Windows audio quality guy here[1]

This is due to a bug in Windows audio service; we have a fix for it locally and we're testing it out. What's happening is that the audio service is internally impersonating the app (the Firefox content process) and then calling into another component to verify that the app has access to the microphone; but because the Firefox content process is (correctly) running with a restricted token, the call to the other component is blocked, and the ERROR_ACCESS_DENIED is fallout from this.

[1] https://blogs.msdn.microsoft.com/matthew_van_eerde/

Comment 14

[David Parks [:handyman]]

Hey Bob, looks like Matthew may be our savior here ^^.

Comment 15

[Bob Owen (:bobowen) PTO until 13th Aug]

(In reply to David Parks (dparks) [:handyman] from comment #14)
> Hey Bob, looks like Matthew may be our savior here ^^.

\o/

Thanks for letting us know Matthew, do you have any idea when the fix might make its way into the preview build?

Comment 16

[Matthew van Eerde]

Builds 17073 and later have the fix

Comment 17

[Bob Owen (:bobowen) PTO until 13th Aug]

Sam - Insider Preview Build 17074 has just been announced. This should have the fix, would you mind confirming this?

Comment 18

[samlh]

Yes, I can confirm both the test page and the original page I was trying (https://voice.mozilla.org/record) are now fixed. 

This is with windows 10.0.17074 Build 17074 and Firefox 59.0a1 (2018-01-10) (64-bit).

Comment 19

[Bob Owen (:bobowen) PTO until 13th Aug]

(In reply to samlh from comment #18)
> Yes, I can confirm both the test page and the original page I was trying
> (https://voice.mozilla.org/record) are now fixed. 
> 
> This is with windows 10.0.17074 Build 17074 and Firefox 59.0a1 (2018-01-10)
> (64-bit).

Excellent, thanks for checking and for the original bug report.
As this is an OS fix, I think it's safe to mark all Firefox versions fixed.