Project Fission: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=Project Fission= | =Project Fission= | ||
Project Fission is the code named assigned to our long term Spectre mitigation strategy of isolating process per origin (aka Site Isolation). | Project Fission is the code named assigned to our long term [https://spectreattack.com/spectre.pdf Spectre] mitigation strategy of isolating process per origin (aka Site Isolation). | ||
How Project Fission Mitigates Spectre | How Project Fission Mitigates Spectre | ||
Spectre allows one origin to steal the user’s or another origin’s private data using one of the above variants; but only data in the same process address space. Fission mitigates Spectre by moving all the private data that an origin shouldn’t be able to access into a separate process. That way, even if a Spectre variant is successfully used, there is no private data to steal. Importantly, this avoids having to mitigate each Spectre variant (Variant examples omitted for Security purposes) individually. | Spectre allows one origin to steal the user’s or another origin’s private data using one of the above variants; but only data in the same process address space. Fission mitigates Spectre by moving all the private data that an origin shouldn’t be able to access into a separate process. That way, even if a Spectre variant is successfully used, there is no private data to steal. Importantly, this avoids having to mitigate each Spectre variant (Variant examples omitted for Security purposes) individually. | ||
This explanation critically assumes that Spectre variants don’t work across processes. The general answer here is that the Meltdown fixes already deployed ensure this is the case. There is currently a known theoretical cross-process Spectre leak, but Windows already has an opt-in fix which might become the default for all user mode processes. Other than this, we’re not aware of other cross-process Spectre attacks. | This explanation critically assumes that Spectre variants don’t work across processes. The general answer here is that the [https://spectreattack.com/meltdown.pdf Meltdown] fixes already deployed ensure this is the case. There is currently a known theoretical cross-process Spectre leak, but Windows already has an opt-in fix which might become the default for all user mode processes. Other than this, we’re not aware of other cross-process Spectre attacks. | ||
More generally, using Fission to mitigate Spectre aligns browsers with what seems to be the emerging cross-industry contract that the OS+CPU prevent Spectre attacks between userspace and kernel and between separate userspace processes. When trying to isolate mutually untrusted code within a process, all indications are that browsers are on our own from the OS+CPU perspective, which is a risky position. Moreover, the OS+CPU have better tools for stopping cross-process Spectre leaks: PCID, scheduling policy, context switches, page tables, ring 0-only instructions, etc. | More generally, using Fission to mitigate Spectre aligns browsers with what seems to be the emerging cross-industry contract that the OS+CPU prevent Spectre attacks between userspace and kernel and between separate userspace processes. When trying to isolate mutually untrusted code within a process, all indications are that browsers are on our own from the OS+CPU perspective, which is a risky position. Moreover, the OS+CPU have better tools for stopping cross-process Spectre leaks: PCID, scheduling policy, context switches, page tables, ring 0-only instructions, etc. | ||
Revision as of 02:39, 12 April 2018
Project Fission
Project Fission is the code named assigned to our long term Spectre mitigation strategy of isolating process per origin (aka Site Isolation).
How Project Fission Mitigates Spectre Spectre allows one origin to steal the user’s or another origin’s private data using one of the above variants; but only data in the same process address space. Fission mitigates Spectre by moving all the private data that an origin shouldn’t be able to access into a separate process. That way, even if a Spectre variant is successfully used, there is no private data to steal. Importantly, this avoids having to mitigate each Spectre variant (Variant examples omitted for Security purposes) individually.
This explanation critically assumes that Spectre variants don’t work across processes. The general answer here is that the Meltdown fixes already deployed ensure this is the case. There is currently a known theoretical cross-process Spectre leak, but Windows already has an opt-in fix which might become the default for all user mode processes. Other than this, we’re not aware of other cross-process Spectre attacks.
More generally, using Fission to mitigate Spectre aligns browsers with what seems to be the emerging cross-industry contract that the OS+CPU prevent Spectre attacks between userspace and kernel and between separate userspace processes. When trying to isolate mutually untrusted code within a process, all indications are that browsers are on our own from the OS+CPU perspective, which is a risky position. Moreover, the OS+CPU have better tools for stopping cross-process Spectre leaks: PCID, scheduling policy, context switches, page tables, ring 0-only instructions, etc.
Project planning
Project Fission will consist of a Cross Functional engineering team across the Platform organization.
The DOM team is currently engaged in several architectural changes in preparation for isolating process per origin.
Primary Meta bug - Bug 1432593 - (meta) Site Isolation
Other Relevant bugs
Bug 1437994 - Implement Abstract Browsing Context Trees
Bug 1436504 - JS APIs for async communication between DocShells
Bug 1429896 - (meta) Out of Process (OOP) iframes
Bug 1353867 - Implement Cross-Process async window proxies
Bug 1438272 - Move Session History State into the Parent Process
Bug 1445459 - Rework Session Restore for changes to Session History
We are still in the process of scoping the breadth of Project Fission and expect to have additional documents in the coming weeks. Scope, PHD, Project process, Roadmap, and Release criteria are still being formed and expected to be shared over the coming weeks.
Team
Executive Sponsor: Dave Camp
Product Sponsor: Selena Decklemann
Engineering Manager: Andrew Overholt
Project Architect: Nika Lyzell
Project Manager: Thomas Elin
Communications
Find us on SLACK
- #Fission