5 ms·

Is Servo going to employ a multi-process model like Chromium? I am afraid so which makes it very tough for embedding. I see cef_execute_process [1] and what not

Is Servo going to employ a multi-process model like Chromium? I am afraid so which makes it very tough for embedding. I see cef_execute_process [1] and what not are not implemented. Are there plans to implement that far up the embedding API? Hopefully a single-process-yet-multiple-page/tab embedded servo is fully supported (unlike --single-process for CEF/Chromium). 1 - https://github.com/servo/servo/blob/master/ports/cef/core.rs#L100 https://github.com/servo/servo/blob/master/ports/cef/core.rs...

pcwalton 12y ago
Yes, Servo is going to go multi-process. There's a PR to do that already (though it needs a good amount of forward porting at this point). It's hard to say about single-process mode; it'll stay maintained as long as someone's willing to do the maintenance. There isn't anything that's inherently multiprocess about the architecture (for example, there are basically no global variables anywhere in Servo), in any case, so I don't imagine it'll be hard to keep it running. I don't want to make any promises, though.
- higherpurpose 12y ago
  Any thoughts on going multi-"app container" in the future as well? https://blogs.windows.com/msedgedev/2015/05/11/microsoft-edge-building-a-safer-browser/ https://blogs.windows.com/msedgedev/2015/05/11/microsoft-edg...
  - pcwalton 12y ago
    That's essentially a detail of the Windows sandbox implementation. Servo's sandboxing story is Rust's gaol library [1], which has no support for Windows yet, but any multiprocess deployment on Windows would want to be accompanied by a sandbox utilizing those kinds of features. [1]: https://github.com/pcwalton/gaol https://github.com/pcwalton/gaol
- infogulch 12y ago
  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. [0]: https://www.chromium.org/developers/design-documents/multi-process-architecture https://www.chromium.org/developers/design-documents/multi-p...
  - brson 12y ago
    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.
    - TD-Linux 12y ago
      Not only that, but the Javascript JIT emitted code is unsafe. There is no way to guarantee its safety, even with a JIT implemented in Rust.
  - kibwen 12y ago
    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!).
    - infogulch 12y ago
      > 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.
guelo 12y ago
Maybe I don't understand what you're asking, but when I think of embedding I think of the embedded component running in my process. Is that not the case with chormium? If it's its own process how do you interact with it?
om2 12y ago
It's entirely possible to make a multiprocess browser engine with a clean embedding API. WebKit does it, for instance. You can use WKWebView to pretty easily make your own process-per-tab browser.

pcwalton 12y ago

Yes, Servo is going to go multi-process. There's a PR to do that already (though it needs a good amount of forward porting at this point). It's hard to say about single-process mode; it'll stay maintained as long as someone's willing to do the maintenance. There isn't anything that's inherently multiprocess about the architecture (for example, there are basically no global variables anywhere in Servo), in any case, so I don't imagine it'll be hard to keep it running. I don't want to make any promises, though.

higherpurpose 12y ago
Any thoughts on going multi-"app container" in the future as well? https://blogs.windows.com/msedgedev/2015/05/11/microsoft-edge-building-a-safer-browser/ https://blogs.windows.com/msedgedev/2015/05/11/microsoft-edg...
- pcwalton 12y ago
  That's essentially a detail of the Windows sandbox implementation. Servo's sandboxing story is Rust's gaol library [1], which has no support for Windows yet, but any multiprocess deployment on Windows would want to be accompanied by a sandbox utilizing those kinds of features. [1]: https://github.com/pcwalton/gaol https://github.com/pcwalton/gaol
infogulch 12y ago
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. [0]: https://www.chromium.org/developers/design-documents/multi-process-architecture https://www.chromium.org/developers/design-documents/multi-p...
- brson 12y ago
  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.
  - TD-Linux 12y ago
    Not only that, but the Javascript JIT emitted code is unsafe. There is no way to guarantee its safety, even with a JIT implemented in Rust.
- kibwen 12y ago
  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!).
  - infogulch 12y ago
    > 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.

guelo 12y ago

Maybe I don't understand what you're asking, but when I think of embedding I think of the embedded component running in my process. Is that not the case with chormium? If it's its own process how do you interact with it?

om2 12y ago

It's entirely possible to make a multiprocess browser engine with a clean embedding API. WebKit does it, for instance. You can use WKWebView to pretty easily make your own process-per-tab browser.