4 ms·

Thoughtful and insightful answer. Although I am on the other side of your argument. I like your rationale around other cloud providers’ virtualization solution

Thoughtful and insightful answer. Although I am on the other side of your argument. I like your rationale around other cloud providers’ virtualization solutions. I think the main comparison that’s lacking is one of v8 isolates vs strict site isolation which runs on separate processes. Why would the Chrome team build such a complex thing if v8 isolates passed rigorous security standards/bar etc? This would be good to get your insights on. What’s the actual cost of separate processes vs v8 isolate? In terms of cpu/memory/latency mainly. I would guess either would win over other virtualization techniques but between the two is it really that stark of a difference? I am more and more convinced you may have seen the light shine through and people such as me are missing the big picture: so providing answers for this line of attack would be more helpful than comparing with other virtualization mechanisms.

kentonv 4y ago
> Why would the Chrome team build such a complex thing if v8 isolates passed rigorous security standards/bar etc? This question assumes that there exists some threshold of "rigorous security standards" which clearly separates "secure" from "insecure". There's no such threshold. We know that risks always exist. No one can precisely quantify those risks. We can only sort of abstractly debate about which risks might be large, and take precautions by addressing those risks with defense-in-depth measures. Each such measure must, of course, be weighed against the costs -- both development costs and runtime costs. Chrome made the decision that strict site isolation was a worthwhile trade-off to reduce risks. I generally agree with this decision. In Chrome's case, the overhead of extra processes turned out to be acceptable, and I think the risk reduction was meaningful. In Cloudflare Workers' case, the cost of isolating every Worker in its own process would be much higher. We actually have the ability to do such isolation, and we selectively apply it in cases where we have other signals to suggest that risk may be elevated (such as when the Worker's performance characteristics suggest it may be engaging in a Spectre attack). But because Workers are designed to handle fine-grained events and often run for less than a millisecond at a time, the overhead of this isolation is much higher than in Chrome's case. The exact overhead depends on what the Worker is doing, but 5x-10x is typical (both for CPU and memory). Given this, implementing strict process isolation would not be a good trade-off for us. Some people respond to this with "You can't sacrifice security for performance!!!", but this is naive. Again, all of the big cloud providers are trading off a whole lot of security risk for performance when they choose to run untrusted native code. In the real world we always make trade-offs. Meanwhile, though, there are lots of other types of defense in depth that we can implement in Workers that isn't so easy to do in browsers. Dynamic process isolation is one example. Another is that we can automatically roll out V8 patches to production much faster than Chrome can. See the blog post I linked for some more examples.
- Veserv 4y ago
  There do exist rigorous security standards that have been theoretically and empirically demonstrated to distinguish "secure" from "insecure" as long as we take those terms to mean something meaningful like, "can protect from state-level actors" and "can not protect from actors of average skill" which constitutes a difference of literal orders of magnitude. In fact, it even comes in the form of internationally recognized standards such as the Common Criteria (ISO 15408). In the general space of multi-level systems enforcing isolation between untrusted code and trusted data, we can look to the SKPP [1] or the Orange Book Class A1 [2]. [1] https://www.niap-ccevs.org/MMO/PP/pp_skpp_hr_v1.03.pdf https://www.niap-ccevs.org/MMO/PP/pp_skpp_hr_v1.03.pdf [2] https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf https://csrc.nist.gov/csrc/media/publications/conference-pap...

kentonv 4y ago

> Why would the Chrome team build such a complex thing if v8 isolates passed rigorous security standards/bar etc? This question assumes that there exists some threshold of "rigorous security standards" which clearly separates "secure" from "insecure". There's no such threshold. We know that risks always exist. No one can precisely quantify those risks. We can only sort of abstractly debate about which risks might be large, and take precautions by addressing those risks with defense-in-depth measures. Each such measure must, of course, be weighed against the costs -- both development costs and runtime costs. Chrome made the decision that strict site isolation was a worthwhile trade-off to reduce risks. I generally agree with this decision. In Chrome's case, the overhead of extra processes turned out to be acceptable, and I think the risk reduction was meaningful. In Cloudflare Workers' case, the cost of isolating every Worker in its own process would be much higher. We actually have the ability to do such isolation, and we selectively apply it in cases where we have other signals to suggest that risk may be elevated (such as when the Worker's performance characteristics suggest it may be engaging in a Spectre attack). But because Workers are designed to handle fine-grained events and often run for less than a millisecond at a time, the overhead of this isolation is much higher than in Chrome's case. The exact overhead depends on what the Worker is doing, but 5x-10x is typical (both for CPU and memory). Given this, implementing strict process isolation would not be a good trade-off for us. Some people respond to this with "You can't sacrifice security for performance!!!", but this is naive. Again, all of the big cloud providers are trading off a whole lot of security risk for performance when they choose to run untrusted native code. In the real world we always make trade-offs. Meanwhile, though, there are lots of other types of defense in depth that we can implement in Workers that isn't so easy to do in browsers. Dynamic process isolation is one example. Another is that we can automatically roll out V8 patches to production much faster than Chrome can. See the blog post I linked for some more examples.

Veserv 4y ago
There do exist rigorous security standards that have been theoretically and empirically demonstrated to distinguish "secure" from "insecure" as long as we take those terms to mean something meaningful like, "can protect from state-level actors" and "can not protect from actors of average skill" which constitutes a difference of literal orders of magnitude. In fact, it even comes in the form of internationally recognized standards such as the Common Criteria (ISO 15408). In the general space of multi-level systems enforcing isolation between untrusted code and trusted data, we can look to the SKPP [1] or the Orange Book Class A1 [2]. [1] https://www.niap-ccevs.org/MMO/PP/pp_skpp_hr_v1.03.pdf https://www.niap-ccevs.org/MMO/PP/pp_skpp_hr_v1.03.pdf [2] https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf https://csrc.nist.gov/csrc/media/publications/conference-pap...