On Jun 3, 2016, at 8:53 AM, Ted Mielczarek <t...@mielczarek.org> wrote:
> On Wed, May 25, 2016, at 10:27 PM, Eric Rescorla wrote: >> - Making it so that certain kinds of defects still happen but they are >> safer. >> For instance, in C writing dereferencing past the end of an array is >> undefined behavior and may well cause something horrible, in Python >> you get an exception, which, if not caught, causes program termination. >> It's safer in the sense that it's unlikely to cause a security >> vulnerability, >> but it's still a crash. > > Right. There are two main reasons we track and fix crashes: > 1) They are often a sign of potentially exploitable code, and we don't > want security holes in our product. > 2) They create a bad user experience. > > Moving code from C++ to JS or Rust improves our story around #1, since > it mitigates classes of vulnerabilities, but it still leaves us open to > #2, where we terminate the app unexpectedly and users are unhappy. I > think Rust does give us a better story here, since we can safely > restrict panics to individual threads, and as long as you don't unwrap > the thread result you don't have to propagate that panic across threads. To add to #2, restricting panics is a key part of the design of Servo. We work pretty hard to ensure that a panic in a single iframe is isolated from the rest of the tab so that we can just crash the buggy ad banner, social media widget, etc. and hopefully keep the main content acting normally. Certainly, there are some places where that's hard for us to do (shared tasks such as resource loading, only taking down one of several same-origin iframes sharing a script task / SM JSRuntime instance, etc.) but we hope that using Rust to install backstops a point more fine-grained than the entire tab or content process will be a big improvement. It will also be challenging to replicate in C++ with the thread-per-tab or process-per-domain models either in use or planned in other engines. - Lars _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
