Bug 1322426 (socket-proc)

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

NEW
Assigned to

Status

()

P2
normal
2 years ago
19 days ago

People

(Reporter: bkelly, Assigned: schien)

Tracking

(Depends on: 17 bugs, Blocks: 4 bugs, {parity-safari, sec-want})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-active], URL)

(Reporter)

Description

2 years ago
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]
(Reporter)

Comment 1

2 years ago
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.
(Reporter)

Comment 3

2 years ago
(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.
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
Blocks: 1405734

Updated

10 months ago
Depends on: 1416623
Alias: socket-proc
Summary: Move all TCP/UDP network operations into a dedicated process → [meta] Move all TCP/UDP network operations into a dedicated process
Depends on: 1430041
Depends on: 1430042
Depends on: 1430045
Depends on: 1430047
Depends on: 1430048
Depends on: 1430050
Depends on: 1430538
Depends on: 1430684
Depends on: 1430695
See Also: → bug 1431022

Updated

6 months ago
Blocks: 1359559

Updated

6 months ago
Keywords: parity-safari, sec-want
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

Updated

5 months ago
Blocks: 1451850

Updated

5 months ago
Blocks: 1456285
See Also: → bug 1396030

Updated

a month ago
Depends on: 1483276
Depends on: 1484743
Depends on: 1484751
Depends on: 1485619
Depends on: 1485652

Updated

26 days ago
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.
You need to log in before you can comment on or make changes to this bug.