On Nov 15, 2012, at 12:02 AM, Ryosuke Niwa <[email protected]> wrote:
> On Wed, Nov 14, 2012 at 11:37 PM, Chris Evans <[email protected]> wrote: > On Wed, Nov 14, 2012 at 10:29 PM, Ryosuke Niwa <[email protected]> wrote: > In other words, why are you interested in using the proposed allocation > mechanism for only DOM nodes/objects instead of everything in WebCore/WebKit? > > The challenge is to add partitioning without going too crazy on number of > partitions, whilst maximizing benefit (i.e minimizing the options the > attacker has.) > > If we stuff every virtual class in WebCore/WebKit together, the attacker has > just tons of options for overlap of freed object and attacker-chosen object. > The situation is complicated by the presence of multiple vtables in some > classes. > > Right. That kind of trade off makes sense. > > But there’s also a danger of making our codebase too complex. As you’re well > aware, increasing code complexity will lead to more bugs including but not > limited to security bugs. I’ve been seen many new and even some experienced > contributors introducing memory management bugs because they’re not used to > either RefCounted objects or RenderArena allocated objects because many > people tend to work on either rendering code or DOM code but not both. > > If we’re deploying RenderArea for DOM nodes, I’d like to make sure we have a > solid API that’s extremely hard to misuse (in addition to making sure > adopting a node from one document to another doesn’t result in pathological > performance, etc…). You can achieve all this by having only one global custom allocator for all objects inheriting from Node, instead of one per Document based on RenderArena. They could stay RefCounted and would just need to overload operator new and operator delete at the Node level. There would be no need to pass around arena pointers and clients of Node and its subclasses would not even have to be aware of the difference. Still not convince that just targeting Node subclasses is a rational solution. > > To come up with the suggestion of partitioning off the Node hierarchy, I > actually did a "blind" analysis against the Pinkie Pie exploit. i.e. I picked > the best defense idea we had without fully dissecting the exploit and then > ran an analysis of how the defense would have impacted the exploitability. > With the defense in place, the attacker's options for this particular case > turned out to be severely limited and I couldn't find a good place to start. > I even managed to locate and chat to Pinkie Pie who described the proposed > defense as "quite useful". > > Are there other exploits we can get data from? Getting statistics from one > exploit results in a strong sampling bias so ideally we can assess whether > slab memory allocation is a good defense against other types of exploits. I tend to agree that if we make a memory allocation architecture change, it should be based on sample size > 1. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
