On Tue, May 26, 2009 at 10:54 PM, Evan Martin<[email protected]> wrote: > > On Tue, May 26, 2009 at 1:06 PM, Adam Langley <[email protected]> wrote: >> But we've gone over this before? Zygotes disable ASLR, make debugging harder >> etc. They might have some performance benefits, but I don't believe that >> they're the correct solution for the auto update issue. > > I suggested Dan bring this up on chromium-dev so we could hash it out > publicly. :) > > (For context for the rest of the list: the question is whether we > re-fork a preforked "zygote" renderer subprocess or do a new fork/exec > of our binary when we want a new renderer process.) > > Here's a list of the issues I've heard about. > > > ASLR: you say it disables ASLR, but it seems you get whatever > randomized address space the initial zygote got. Net effect is that > within a given browser instance each renderer will have the same > layout. How bad is that? (Honest question, not suggesting it isn't > bad.)
There are two things that seemed medium bad to me about zygotes and ASLR. - The renderers always have the same layout, meaning if you could find some bug that allowed you to spawn a new tab/process, attack it, and let it crash, you could brute force addresses until you hit it. Although, I suppose the probability is similar either way. - The browser and renderers share the same layout. If you can find a pointer leak / bug in the renderer, you then know the address layout to try and attack the browser process. > > Debugging: you say it's harder, but I'm not sure why. Because of the > renderer-cmd-prefix stuff? But gdb is just as capable of attaching to > a pid -- rather than --renderer-cmd-prefix='xterm -e gdb' we could > just as well do --renderer-cmd-pid-prefix='xterm -e gdb -p'. > > On the pro-zygote side, issues we have: > > Updates clobbering our files. If we open everything before we fork > we're good. (I'm not confident that we can open everything we want > before we fork -- the inspector is a collection of random files > scattered in /usr/share. But the inspector problem applies to any > solution I've yet seen and we ought to be able to pack it into one > mmappable file if we want.) > > Sharing: with zygotes, each instance of webkit shares memory pages, > even the ones we tweak after renderer startup but before we fork. > > Performance: may be faster to start renderers if we've preforked. > > Sharing/performance of course don't count as benefits until we have > numbers to support them. Dan did preliminary measurements and found > no perf win, but I don't know if we have tests that measure the > performance of starting many tabs. > >> However, we could easily make a hardlink with a specific version in the name. >> That could go wrong if packaging systems write the same inode when updating >> rather than creating a new one, but I suspect that they don't. A patch to use >> the zygote hammer for the auto-updating issue would first have to show that >> there's no easier alternatives! > > I don't have a strong opinion on what we should do here beyond "right > now we're broken and we should fix that". We can imagine many > solutions but each time there's a bit of hand-waving. Perhaps you > could make a concrete counterproposal? (Again, I don't mean that to > sound as hostile as it might seem -- I honestly think it'd be good to > be able to weigh pros/cons of approaches.) > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
