6 ms·

The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to d

by comex 14y ago

The claim that process isolation is "antiquated" is absurd, since it's what everyone else is doing except for those, like Firefox, who have not yet started to do anything at all. I don't know any other projects that do what NaCl does, so regardless of whether Google should switch to pure NaCl for sandboxing, if they did, it would be innovation, not scrapping an antiquated technology. As for whether they should - although Native Client's software fault isolation can provide better latency than hardware-based solutions because there's no need for a context switch, it takes a hit in throughput (7% overhead) because of the code contortions involved (though being able to trust the executable code might improve things). There would be significant issues with supporting JIT in such a model, because JITs typically like to have rwx memory. Multiple sandboxes in the same process wouldn't work with the current NaCl model on 32-bit platforms. And although the SFI has been well secured, putting user code in the same address space as the master process might make exploitation easier - this would be partially mitigated if the address of the user code could be hidden from it, but doing that would require additional overhead because addresses could no longer be stored directly on the stack.

stcredzero 14y ago
> The claim that process isolation is "antiquated" is absurd Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.
- loeg 14y ago
  I don't know about these claims — just because most OS research is now 20+ years old doesn't mean that a result, process isolation, is antiquated. You likely use a very modern operating system with process time-sharing (1964) using virtual memory (1950s/1960s) and so many other results of OS research from 30+ years ago… This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.
zobzu 14y ago
Yup, I think some people don't realize why processes exist and what they're here for. It just looks like a concept that we've been using for a long time so, "it must be too old and be replaced", without understanding _how_ it works and _why_ it's there.
- gtirloni 14y ago
  As everything in IT.
cpeterso 14y ago
Firefox uses a sandbox process for plugins like Flash. Mozilla implemented per-tab processes, a project called Electrolysis, but it would break many popular add-ons. Firefox OS is able to use process isolation, through, because it doesn't need to support legacy add-ons.
- comex 14y ago
  Really? I haven't heard a single thing about Electrolysis in a long time, except I remember reading somewhere recently that it was abandoned. I'm happy to hear that Firefox OS is using it; still, keeping legacy add-ons working seems like a bad reason to stop pursuing such an important security feature on the desktop.
  - bzbarsky 14y ago
    Electrolysis was suspended for desktop Firefox. Firefox on Android used to use Electrolysis until it switched to the current Java front-end. And FirefoxOS is using it for sure: process per app, so that apps can be easily killed in low-memory conditions. As for "legacy add-ons", that would be "every single add-on". Not to mention that the desktop Firefox UI itself would have to be heavily rewritten as well. The judgement, as mcpherinm says, was that the cost was too high for the possible gains. I agree that process isolation is good for security, but there are various other security mitigation strategies that can be used that had a higher bang for the buck at the time.
  - mcpherrinm 14y ago
    I was employed at Mozilla when the pronouncement to "suspend" work on Electrolysis came from on high. I think addons are a small part of the picture. The big deal is there are only so many Firefox developers, and Electrolysis was turning into a real sinkhole of time with no end in sight. There were a lot better ways to make Firefox a better browser in the meantime, and those things are being done.
mistercow 14y ago
The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.
- azakai 14y ago
  > The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
  - stanleydrew 14y ago
    If he actually intended to say that why didn't he just say it? The fact that he leaves us guessing is puzzling.
  - bengoodger 14y ago
    I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day. [1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org http://build.chromium.org
    - azakai 14y ago
      > I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
dxdt 14y ago
There's no way that "resource-intensive and unpredictably timed context switches" account for 100-200ms on modern hardware. With modern multi-core/cpu boxes I think a typical time for a context switch is on the order of 10 microseconds, and that doesn't take into account in things like CPU affinity. (It's still going to depend on a lot on OS and hardware. For example: new i7 vs old core architecture) If there's actually high costs, it shouldn't be due to a "antiquated" multi-process architecture, but other things like marshalling data to and from the JS engine.

by comex 14y ago

stcredzero 14y ago

> The claim that process isolation is "antiquated" is absurd Either this is hyperbole, or it means the author is aware of research or a technology that the tech mainstream is unaware of.

loeg 14y ago
I don't know about these claims — just because most OS research is now 20+ years old doesn't mean that a result, process isolation, is antiquated. You likely use a very modern operating system with process time-sharing (1964) using virtual memory (1950s/1960s) and so many other results of OS research from 30+ years ago… This is how science works: research suggests some result; until other research suggests a different result, the first result is our best working hypothesis. Process isolation is hardly antiquated.

zobzu 14y ago

Yup, I think some people don't realize why processes exist and what they're here for. It just looks like a concept that we've been using for a long time so, "it must be too old and be replaced", without understanding _how_ it works and _why_ it's there.

gtirloni 14y ago
As everything in IT.

cpeterso 14y ago

Firefox uses a sandbox process for plugins like Flash. Mozilla implemented per-tab processes, a project called Electrolysis, but it would break many popular add-ons. Firefox OS is able to use process isolation, through, because it doesn't need to support legacy add-ons.

comex 14y ago
Really? I haven't heard a single thing about Electrolysis in a long time, except I remember reading somewhere recently that it was abandoned. I'm happy to hear that Firefox OS is using it; still, keeping legacy add-ons working seems like a bad reason to stop pursuing such an important security feature on the desktop.
- bzbarsky 14y ago
  Electrolysis was suspended for desktop Firefox. Firefox on Android used to use Electrolysis until it switched to the current Java front-end. And FirefoxOS is using it for sure: process per app, so that apps can be easily killed in low-memory conditions. As for "legacy add-ons", that would be "every single add-on". Not to mention that the desktop Firefox UI itself would have to be heavily rewritten as well. The judgement, as mcpherinm says, was that the cost was too high for the possible gains. I agree that process isolation is good for security, but there are various other security mitigation strategies that can be used that had a higher bang for the buck at the time.
- mcpherrinm 14y ago
  I was employed at Mozilla when the pronouncement to "suspend" work on Electrolysis came from on high. I think addons are a small part of the picture. The big deal is there are only so many Firefox developers, and Electrolysis was turning into a real sinkhole of time with no end in sight. There were a lot better ways to make Firefox a better browser in the meantime, and those things are being done.

mistercow 14y ago

The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.

azakai 14y ago
> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
- stanleydrew 14y ago
  If he actually intended to say that why didn't he just say it? The fact that he leaves us guessing is puzzling.
- bengoodger 14y ago
  I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day. [1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org http://build.chromium.org
  - azakai 14y ago
    > I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.

dxdt 14y ago

There's no way that "resource-intensive and unpredictably timed context switches" account for 100-200ms on modern hardware. With modern multi-core/cpu boxes I think a typical time for a context switch is on the order of 10 microseconds, and that doesn't take into account in things like CPU affinity. (It's still going to depend on a lot on OS and hardware. For example: new i7 vs old core architecture) If there's actually high costs, it shouldn't be due to a "antiquated" multi-process architecture, but other things like marshalling data to and from the JS engine.