119
edits
Changes
no edit summary
=Project Fission=
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
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 [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.
