Really approachable article, very well written, I think. This is quite an interesting technique, Chrome was sort of built on leveraging OS level sandboxing for so long, even contributing entirely new methods of sandboxing to operating systems, or doing sort of nutty things to get their sandbox stronger. This is now going in the other direction - putting more and more sandboxing into the runtime itself.
The V8 Sandbox is a new security mechanism designed to prevent memory corruption in V8 from impacting other memory in the process. The sandbox is motivated by the fact that current memory safety technologies are largely inapplicable to optimizing JavaScript engines. While these technologies fail to prevent memory corruption in V8 itself, they can in fact protect the V8 Sandbox attack surface. The sandbox is therefore a necessary step towards memory safety.
I think it’s unsurprising that at some point you probably do want memory safety enforced in a more “traditional” way, despite that the nature of JITs makes it much less useful. With more people running in a strictly interpreted mode for security I think that’s probably going to be especially true.
Really approachable article, very well written, I think. This is quite an interesting technique, Chrome was sort of built on leveraging OS level sandboxing for so long, even contributing entirely new methods of sandboxing to operating systems, or doing sort of nutty things to get their sandbox stronger. This is now going in the other direction - putting more and more sandboxing into the runtime itself.
I think it’s unsurprising that at some point you probably do want memory safety enforced in a more “traditional” way, despite that the nature of JITs makes it much less useful. With more people running in a strictly interpreted mode for security I think that’s probably going to be especially true.
Didn’t WebKit have this for years?