Use of win32k APIs in content process for webrtc task queue

NEW
Unassigned

Status

()

P3
normal
Rank:
25
a year ago
5 months ago

People

(Reporter: Alex_Gaynor, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 affected)

Details

(Reporter)

Description

a year ago
The sandboxing team is currently exploring what would be required to remove all win32k usage from the content process. WebRTC appears to be one of the consumers of win32k APIs. Here are two example stacks:

    win32u!NtUserPostThreadMessage
    USER32!PostThreadMessageW+0x32
    xul!rtc::TaskQueue::~TaskQueue+0x6e
    xul!webrtc::internal::Call::~Call+0x384
    xul!webrtc::internal::Call::`scalar
    xul!mozilla::DefaultDelete<webrtc::Call>::operator()+0x7
    xul!mozilla::UniquePtr<webrtc::Call,mozilla::DefaultDelete<webrtc::Call>
    xul!mozilla::WebRtcCallWrapper::~WebRtcCallWrapper+0x60
    xul!mozilla::WebRtcCallWrapper::`scalar
    xul!mozilla::detail::RefCounted<mozilla::WebRtcCallWrapper,1>::Release+0x36
    xul!mozilla::RefPtrTraits<mozilla::WebRtcCallWrapper>::Release+0x8
    xul!RefPtr<mozilla::WebRtcCallWrapper>::ConstRemovingRefPtrTraits<mozilla::WebRtcCallWrapper>::Release+0x8
    xul!RefPtr<mozilla::WebRtcCallWrapper>::{dtor}+0xf
    xul!mozilla::PeerConnectionMedia::~PeerConnectionMedia+0x100
    xul!mozilla::PeerConnectionMedia::`scalar
    xul!mozilla::PeerConnectionMedia::Release+0x44
    xul!mozilla::PeerConnectionMedia::SelfDestruct_m+0x97





    win32u!NtUserPostThreadMessage
    USER32!PostThreadMessageW+0x32
    xul!rtc::TaskQueue::~TaskQueue+0x6e
    xul!webrtc::AudioDeviceBuffer::~AudioDeviceBuffer+0x17d
    xul!webrtc::AudioDeviceModuleImpl::~AudioDeviceModuleImpl+0xc4
    xul!rtc::RefCountedObject<webrtc::AudioDeviceModuleImpl>::{dtor}+0xb
    xul!rtc::RefCountedObject<webrtc::AudioDeviceModuleImpl>::`scalar
    xul!rtc::RefCountedObject<webrtc::AudioDeviceModuleImpl>::Release+0x1a
    xul!rtc::scoped_refptr<webrtc::AudioDeviceModule>::operator=+0x20
    xul!rtc::scoped_refptr<webrtc::AudioDeviceModule>::operator=+0x9
    xul!webrtc::voe::SharedData::set_audio_device+0xf
    xul!webrtc::VoEBaseImpl::TerminateInternal+0x137
    xul!webrtc::VoEBaseImpl::Terminate+0x20
    xul!mozilla::MediaEngineWebRTCMicrophoneSource::DeInitEngine+0x12
    xul!mozilla::MediaEngineWebRTCMicrophoneSource::Deallocate+0x40
    xul!mozilla::MediaDevice::Deallocate+0x12
    xul!mozilla::SourceListener::StopTrack::__l2::<lambda_1cccf4733557b2b5acea39d2162e0e3d>::operator()+0x2b
Rank: 25
Priority: -- → P2
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
(Reporter)

Comment 2

a year ago
Not sure if this should be a separate bug or if it'd be easier to just include this here, but webrtc audio session initialization also invokes some win32k APIs:

    win32u!NtUserRegisterWindowMessage
    USER32!RegisterWindowMessageW+0x2c
    WINMMBASE!JoyInit+0x3c
    WINMMBASE!InitDevices+0x143
    WINMMBASE!ClientUpdatePnpInfo+0xb2
    WINMMBASE!mixerGetNumDevs+0xb
    xul!webrtc::AudioMixerManager::EnumerateAll+0x37
    xul!webrtc::AudioDeviceWindowsWave::Init+0x82
    xul!webrtc::AudioDeviceModuleImpl::Init+0x103
    xul!webrtc::VoEBaseImpl::Init+0x269
    xul!mozilla::WebrtcAudioConduit::Init+0xe0
    xul!mozilla::AudioSessionConduit::Create+0x9e
    xul!mozilla::MediaPipelineFactory::GetOrCreateAudioConduit+0x83
    xul!mozilla::MediaPipelineFactory::CreateOrUpdateMediaPipeline+0x410
    xul!mozilla::PeerConnectionMedia::UpdateMediaPipelines+0xba
    xul!mozilla::PeerConnectionImpl::SetSignalingState_m+0x126
    xul!mozilla::PeerConnectionImpl::SetLocalDescription+0x2c8
    xul!mozilla::PeerConnectionImpl::SetLocalDescription+0x7c
    xul!mozilla::dom::PeerConnectionImplBinding::setLocalDescription+0xdc
Hey Jesup, do you know if this is the "old device layer" of webrtc? If so I think the removal of this is being handled in bug 1394163.
Flags: needinfo?(rjesup)
>     win32u!NtUserRegisterWindowMessage
>     USER32!RegisterWindowMessageW+0x2c
>     WINMMBASE!JoyInit+0x3c
>     WINMMBASE!InitDevices+0x143
>     WINMMBASE!ClientUpdatePnpInfo+0xb2
>     WINMMBASE!mixerGetNumDevs+0xb
>     xul!webrtc::AudioMixerManager::EnumerateAll+0x37
>     xul!webrtc::AudioDeviceWindowsWave::Init+0x82
>     xul!webrtc::AudioDeviceModuleImpl::Init+0x103
>     xul!webrtc::VoEBaseImpl::Init+0x269
>     xul!mozilla::WebrtcAudioConduit::Init+0xe0
>     xul!mozilla::AudioSessionConduit::Create+0x9e
>     xul!mozilla::MediaPipelineFactory::GetOrCreateAudioConduit+0x83
>     xul!mozilla::MediaPipelineFactory::CreateOrUpdateMediaPipeline+0x410
>     xul!mozilla::PeerConnectionMedia::UpdateMediaPipelines+0xba
>     xul!mozilla::PeerConnectionImpl::SetSignalingState_m+0x126
>     xul!mozilla::PeerConnectionImpl::SetLocalDescription+0x2c8
>     xul!mozilla::PeerConnectionImpl::SetLocalDescription+0x7c
>     xul!mozilla::dom::PeerConnectionImplBinding::setLocalDescription+0xdc

My previous comment was about this stack, not the TaskQueue related calls.
Yes. webrtc::AudioDeviceModule/etc are the stuff we're removing use of.
Flags: needinfo?(rjesup)

Updated

a year ago
Depends on: 1394163

Comment 6

5 months ago
Over in bug 1376873 we are working on updating the webrtc.org code base to version 64. From looking at the new code it seems to that updating it to 64 will result in the PostThreadMessage going to dis-appear.
Depends on: 1376873
You need to log in before you can comment on or make changes to this bug.