canmove, Confirmed users
1,220
edits
Security/Sandbox/Process model: Difference between revisions
Jump to navigation
Jump to search
Security/Sandbox/Process model (view source)
Revision as of 03:17, 14 November 2018
, 14 November 2018→Future Process Types: update file process notes
Ptheriault (talk | contribs) |
Ptheriault (talk | contribs) (→Future Process Types: update file process notes) |
||
| Line 46: | Line 46: | ||
* OSX: [[Security/Sandbox#NPAPI_Flash_Process]] | * OSX: [[Security/Sandbox#NPAPI_Flash_Process]] | ||
=== File (File://) Content Process === | |||
=== File Content Process === | Firefox is separates pages loaded from “file://” page loads in order to support more tightly restricting read access from regular web content processes. Since file:// page loads are forbidden from web content, this allows Firefox to prevents regular web content processes from accessing the local filesystem directly. | ||
Note that the reverse is not forbidden: content loaded from file:// is permitted to load remote web content. | |||
=== GPU Process === | |||
=== | |||
There is currently an ongoing project in the graphics team to move the compositor from the parent process to a separate process (roughly FF53). Currently child processes allocate shared memory for texture data, write to it, and then pass it to the compositor in the Chrome process via IPC. In the new compositor model, the compositor doesn’t need to manage shared memory, but it would be able to keep track of allocations per process and kill child processes using too much memory. In general moving this code will not have a material impact on security posture: | There is currently an ongoing project in the graphics team to move the compositor from the parent process to a separate process (roughly FF53). Currently child processes allocate shared memory for texture data, write to it, and then pass it to the compositor in the Chrome process via IPC. In the new compositor model, the compositor doesn’t need to manage shared memory, but it would be able to keep track of allocations per process and kill child processes using too much memory. In general moving this code will not have a material impact on security posture: | ||
* The child process will still require access to the GPU | * The child process will still require access to the GPU | ||