Bug 1322426 (socket-proc)

[meta] Move all TCP/UDP network operations into a dedicated process

NEW
Assigned to

Status

()

task
P2
normal
3 years ago
Last month

People

(Reporter: bkelly, Assigned: dragana)

Tracking

(Depends on 23 bugs, Blocks 2 bugs, {meta, parity-safari, sec-want})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-active], )

Currently there is work happening to move the GPU compositor into its own process.  This is to improve stability by allowing us to recover from gfx crashes.

Perhaps we should consider doing the same thing for network operations.  We periodically have crashes due to anti-virus and other external actors modifying our network stack.  In addition, new protocols are a potential surface area for crashes and attacks.  Running network code in a separate process would help mitigate crashes and attacks.

As a side effect, it would also reduce contention on the parent process main thread between network requests and other work during page load.
Whiteboard: [necko-backlog]
FWIW, this post mentions chrome is moving to a sandboxed network process soon:

https://medium.com/@justin.schuh/securing-browsers-through-isolation-versus-mitigation-15f0baced2c2#.o8sn6z5ms
A similar idea has been brought up when WebRTC and Necko folks talked at all hands meeting in Hawaii.

Another benefit would be all other processes would no longer need network access for their sandbox, as this would be the only process with network access.

One of the big concerns especially for WebRTC is what are the costs going to be for sending all the real time data across several processes. But we are doing something similar with e10s already, so hopefully this would not much worse in terms of performance.
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #1)
> FWIW, this post mentions chrome is moving to a sandboxed network process
> soon:
> 
> https://medium.com/@justin.schuh/securing-browsers-through-isolation-versus-
> mitigation-15f0baced2c2#.o8sn6z5ms

Also, it seems safari has had a dedicated network process for a while now.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Priority: P3 → P2
Summary: consider performing network operations in a dedicated process → Move all TCP/UPD network operations into a dedicated process
Whiteboard: [necko-backlog] → [necko-active]
Assignee: nobody → schien
Summary: Move all TCP/UPD network operations into a dedicated process → Move all TCP/UDP network operations into a dedicated process
Depends on: 1416623
Summary: Move all TCP/UDP network operations into a dedicated process → [meta] Move all TCP/UDP network operations into a dedicated process
See Also: → 1431022
Blocks: 1359559
This doesn't block bug 1359559 -- that covers locking down the content process sandbox, a network process is about removing attack surface from the parent process.
No longer blocks: 1359559
Blocks: fission
See Also: → 1396030
Depends on: 1483276
Depends on: 1484743
Depends on: 1484751
Depends on: 1484774
Depends on: 1485619
Depends on: 1485652
Depends on: 1486012
Depends on: 1486033
Please note that moving network code to a separate process will mean not receiving Telemetry from that code until the plumbing from bug 1486033 is in place.
Depends on: 1493765
Depends on: 1494301
Depends on: 1494311
Depends on: 1494312
Depends on: 1494585
Depends on: 1494956
Depends on: 1495001
Depends on: 1496464
Depends on: 1494378
Depends on: 1497232
Depends on: 1497235
Depends on: 1497236
Depends on: 1497237
Depends on: 1497238
Depends on: 1497241
Depends on: 1497243
Depends on: 1497245
Depends on: 1497247
Depends on: 1497249
Depends on: 1497270
Depends on: 1503834
For reference, the changeset on larch we stopped the work at, having patches that were both in progress or r+'ed but not landed on larch, is 94a22fd022b9.
I'm hoping this will also benefit Thunderbird, currently typing stalls in composing, when main thread checks email servers for new mail.
Depends on: 1507861
(In reply to Dennis Jakobsen from comment #9)
> I'm hoping this will also benefit Thunderbird, currently typing stalls in
> composing, when main thread checks email servers for new mail.

Is there a reason you think THunderbird will benefit?

Imap in Thunderbird already has it's own, non-blocking (iirc) threads.

pop is main thread/doesn't have its own threads for architectural reasons. Perhaps the tcp can be offloaded there, but I doubt tcp activity related to pop is a major contributor to what you are seeing in Thunderbird
(In reply to Wayne Mery (:wsmwk) from comment #10)
> (In reply to Dennis Jakobsen from comment #9)
> > I'm hoping this will also benefit Thunderbird, currently typing stalls in
> > composing, when main thread checks email servers for new mail.
> 
> Is there a reason you think THunderbird will benefit?
> 
> Imap in Thunderbird already has it's own, non-blocking (iirc) threads.
> 
> pop is main thread/doesn't have its own threads for architectural reasons.
> Perhaps the tcp can be offloaded there, but I doubt tcp activity related to
> pop is a major contributor to what you are seeing in Thunderbird

I have 5 accounts, mixed pop/imap. I'll try and disable auto checking on the pop accounts and confirm what you are saying.

But it's unbearable writing emails when the caret is lagging 5 chars behind what you are typing.
Or maybe i should just request Thunderbird uses a separate thread for the compose window, then they can do all the stuff they want in the main window/thread.
Depends on: 1509405
Depends on: 1509406
Depends on: 1509409
No longer depends on: 1509405
No longer depends on: 1509406
No longer depends on: 1494585
No longer depends on: 1503834
No longer depends on: 1483276
No longer depends on: 1494311
No longer depends on: 1494312
No longer blocks: webrtc-sock-proc
Depends on: 1509822
Depends on: 1509823
No longer depends on: 1507861
Depends on: 1510979
Depends on: 1511318
Depends on: 1513057
Depends on: 1513059
Depends on: 1513175
Depends on: 1513542
Depends on: 1513865
Depends on: 1513872
Depends on: 1515390
Assignee: polo.hellfire → dd.mozilla
Depends on: 1520657
Depends on: 1520805
Depends on: 1520830
Depends on: 1521793
Depends on: 1521817
Depends on: 1523916
Depends on: 1527256
No longer blocks: fission
Depends on: 1527384
Depends on: 1531892
Depends on: 1512598
Depends on: 1537761
Depends on: 1537764
Depends on: 1510691
Depends on: 1539819
Depends on: 1539917
Depends on: 1541894
Type: defect → task
Depends on: 1543168
Depends on: 1543698
Depends on: 1543713
Depends on: 1544745
Depends on: 1544756
Depends on: 1544757
Depends on: 1544777
Depends on: 1545253
Depends on: 1545523
Depends on: 1546355
Depends on: 1546420
Depends on: 1546428
Depends on: 1546537
Depends on: 1546660
Depends on: 1546830
Depends on: 1547389
Depends on: 1547705
Depends on: 1547876
Depends on: 1548726
Depends on: 1549323
Depends on: 1550426
Depends on: 1550686
Depends on: 1551449
Depends on: 1551593
Depends on: 1551849
Depends on: 1551839
Depends on: 1555811
Depends on: 1557178
Depends on: 1557180
Depends on: 1557184
Depends on: 1558469
No longer depends on: 1523916
Depends on: 1559866
No longer depends on: 1430695
No longer depends on: 1527256
No longer depends on: 1539819
No longer depends on: 1543713
No longer depends on: 1557180
You need to log in before you can comment on or make changes to this bug.