1382333 - Synchronous IPC should not require win32k APIs in content process

Status: RESOLVED FIXED

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

Description

[Alex Gaynor [:Alex_Gaynor]]

Currently, some of our IPCs are synchronous, and they use win32k APIs. We should find a way to implement them without win32k. Here's an example offending stack:

    win32u!NtUserCallNoParam
    USER32!RealMsgWaitForMultipleObjectsEx+0xe9
    combase!CCliModalLoop::BlockFn+0x123
    combase!ClassicSTAThreadWaitForHandles+0x9f
    combase!CoWaitForMultipleHandles+0xb3
    xul!mozilla::ipc::MessageChannel::WaitForSyncNotifyWithA11yReentry+0xc5
    xul!mozilla::ipc::MessageChannel::WaitForSyncNotify+0x29
    xul!mozilla::ipc::MessageChannel::Send+0x651
    xul!mozilla::net::PCookieServiceChild::SendGetCookieString+0x16a
    xul!mozilla::net::CookieServiceChild::GetCookieStringInternal+0x19a
    xul!nsHTMLDocument::GetCookie+0x102
    xul!mozilla::dom::HTMLDocumentBinding::get_cookie+0x85

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Part of the problem is that the main thread uses the COM STA. Once nsAppShell is gone we might be able to replace CoWaitForMultipleHandles with WaitForSingleObjectEx in content.

Comment 2

[Bob Owen (:bobowen)]

Fixed by bug 1385014.