The sandbox for windows requires that the target processes shall never
survive the broker processes. In chrome the broker is the browser and
the target is any of the sandboxed processes.
This is enforced by job objects. At a glance this seems a hard thing
to work around.
So on top of the other stuff, chalk some non-trivial changes to the
windows sandbox at the very least.
-cpu
On Dec 18, 2:49 pm, Adam Barth <aba...@chromium.org> wrote:
> On Fri, Dec 18, 2009 at 9:47 AM, Charles Reis <cr...@chromium.org> wrote:
> > Any other examples of browser state that would be tough to restore? How bad
> > would this be for open network connections? (I imagine it's like the
> > network cutting out for a bit.)
>
> Right, we'd have to make sure that every IPC message could "fail"
> similar to how network requests can fail. That could lead to a lot of
> complexity.
>
>
>
> On Fri, Dec 18, 2009 at 10:37 AM, Peter Kasting <pkast...@google.com> wrote:
> > This was the proposed solution when we came up with this idea a while back.
> [...]
> > In the earliest days, we had hoped that the browser side of Chrome would be
> > so lightweight that it could basically be made completely crash-free. It
> > has turned out that that was wildly optimistic.
>
> I'm not surprised this idea has come up before. If I have some time
> to play with this kind of thing, I might try to put together a
> prototype. I'm certainly willing to believe it's more complex that it
> appears at first.
>
> On Fri, Dec 18, 2009 at 10:44 AM, Scott Hess <sh...@google.com> wrote:
> > How would you know which renderer was the one which engineered the
> > crash to cause you to loose some sort of interesting state about that
> > renderer so that it can attack?
>
> That's an interesting problem that we'd have to deal with.
>
> > It might be better to think on performant ways to carve complex bits
> > out of the browser process. Already many of our background threads
> > could probably live in a distinct process and send data back and forth
> > via IPC without too much performance loss. This would have the nice
> > side-effect of not being able to pass pointers between threads (not
> > only would we be protected from crashes, we'd crash less often in the
> > first place!).
>
> Yeah, this is a good approach too. I wonder if we could do this with
> the network stack since it mostly talks to the renderer anyway.
>
> Adam
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
