Hi, On Wed, Aug 03, 2016 at 10:53:39AM +0200, Till Schneidereit wrote:
> I wonder to which extent this matters. I'm not aware of any real-world > instances of the mythical cross-tab information harvesting attack. Sure, in > theory the malvertising ad from one tab would be able to read information > from your online banking session. In practice, it seems like attacks that > gain control of the machine are so much more powerful that that's where all > the focus is. I can't really comment on this assertion, having too little experience in this specific area. However, I believe when discussing merging threads into a single process, several issues are being overlooked: 1) Separate processes are not *only* a security benefit. They also benefit robustness in general: while the Rust thread model allows for some (limited) recovery from thread panics, this doesn't help in various cases: including memory corruption (which is more common than most people realise -- even in the absence of software bugs); threads getting stuck rather than crashing; and threads consuming excessive amounts of resources. Also, unlike threads, malfunctioning processes can be identified and killed from the "outside" using operating system tools -- I found this ability very useful in Chromium. 2) Short-lived, purpose-bound processes greatly help with memory fragmentation -- the bane of Firefox. I believe this is the major reason why Chromium copes way better with a memory-constrained system than Firefox. 3) The assumption that separate processes cause a big overhead and need to be avoided, is mostly wrong I believe. (For a data point, I checked that I can open literally hundreds of tabs in Chromium on my current system with 8 GiB RAM, before it ever decides that memory is becoming scarce, and starts grouping more than one tab per content process.) On the operating system level, there is little difference between threads and processes -- on Linux in fact the kernel treats them pretty much the same, with threads mostly being just processes sharing an address space. Big overheads only come from processes duplicating resources instead of sharing them -- so optimisation IMHO should focus on reducing such duplication, rather than on avoiding processes. The extra complexity of putting several unrelated threads into the same process might actually cause more overhead than it saves... -antrik- _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
