5 ms·

As you scale up with R2, D3, Email Workers etc, is it possible that the _future_ scale of touching very sensitive, "ought-to-be-secure / separate" data / code h

As you scale up with R2, D3, Email Workers etc, is it possible that the _future_ scale of touching very sensitive, "ought-to-be-secure / separate" data / code help reconsider this decision? Without process isolation, all it takes is one bad Chromium commit or a incorrectly allow-listed JS/V8 command for this model to fall through regardless of how thorough the defense-in-depth/vetted Workers may be. "the public clouds that run arbitrary native code in hardware VMs." -> Isn't it double whammy then that a V8 isolate + HW attack surface in combination could provide an order of magnitude more hackability? "Last I heard there were still some lower-powered Android phones where the overhead was too high" -> I believe a Zygote-process fork was made available to Chromium at some point (https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/zygote.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l... ?).

kentonv 4y ago
> all it takes is one bad Chromium commit All it takes is one bad Xen commit, or one bad design choice at Intel, for VM-based clouds to be broken. Every isolation mechanism has bugs, this is not unique to V8. > for this model to fall through regardless of how thorough the defense-in-depth/vetted Workers may be. No no, when I say "defense in depth" I mean we have fallback contingencies to contain the damage of a V8 bug. > Isn't it double whammy then that a V8 isolate + HW attack surface in combination could provide an order of magnitude more hackability? No, the opposite. Having to break two layers at the same time is much harder than breaking just one thing. VM-based clouds are largely counting on just one layer today (most of which is burned into silicon).