What are the benefits of multi-process over merely multi-threaded for a guaranteed memory- and thread-safe language like rust?
In the Chromium Multi-process Architecture design document[0] the benefits boil down to security and stability. While memory safety doesn't guarantee secure logic, it obviates a large class of bugs that a multi-process architecture is designed to counteract. While memory safety doesn't prevent deadlocks, it does completely prevent data race conditions.
You are right that process sandboxing is not as important for Servo, but it is important: 1) more defenses are more better, 2) Servo contains considerable amounts of C and C++ code and will for some time, 3) Even safe Rust has failure modes that can abort the process (primarily out-of-stack), and multiprocess provides recovery for when they happen.
It's important to emphasize that the Servo developers don't consider the fact that Rust is memory-safe to be an excuse to skimp on proven approaches to application security. Servo will still utilize multi-process architecture and sandboxing in order to provide defense-in-depth.
Remember that the goal of Servo is not just to be as safe as modern engines, but to be far safer (while also being twice as fast!).
> not just to be as safe as modern engines, but to be far safer
A worthy goal! However, I'm still concerned. If the project is sufficiently secure without multi-process, adding layers only increases the surface area for attack vectors. Sandboxing not only increases the surface area of your (now) multiple processes, but also introduces the OS layer as an arbiter of communication between them, which we can safely assume does not have memory safety guarantees (though is probably quite hardened).
Of course, the developers would not claim that Servo is "sufficiently secure" right now, especially since (as brson mentioned) it still includes C & C++ source. My point is, sandboxing can be a huge win in terms of security, especially for now; but any complex feature has tradeoffs and the efficacy of those tradeoffs may not continue to hold through the future and should remain open to consideration.
I don't see how a lack of sandboxing would decrease your attack surface, since you need to communicate with the OS somehow. A sandbox just moderates that communication.
I also don't understand "If the project is sufficiently secure without multi-process, adding layers only increases the surface area". The point of layers is that each one needs to be breached in order to craft a full exploit. If one layer is sufficiently secure without multi-process then in the worst case your defense-in-depth is merely redundant, regardless of the attack surface of the remaining layers (though obviously "sufficiently secure" is fairly impossible to prove).
If there is a bug in the mechanism used to ferry messages between the two processes, as that mechanism lives in the kernel, only that one mechanism needs to be breached to attack the computer: sometimes, "layers" are more like a "chain", which are only as strong as the weakest "link". (However, that is much less likely than an issue in the native GUI components, or the apparently non-negligible amount of unsafe C/C++ and JIT'd code used by Servo.)
In the Chromium Multi-process Architecture design document[0] the benefits boil down to security and stability. While memory safety doesn't guarantee secure logic, it obviates a large class of bugs that a multi-process architecture is designed to counteract. While memory safety doesn't prevent deadlocks, it does completely prevent data race conditions.
[0]: https://www.chromium.org/developers/design-documents/multi-p...