[webkit-dev] RenderArena: Teaching an old dog new tricks

Ryosuke Niwa rniwa at webkit.org
Wed Nov 14 22:29:43 PST 2012

On Wed, Nov 14, 2012 at 10:14 PM, Cris Neckar <cdn at chromium.org> wrote:

> On Wed, Nov 14, 2012 at 10:05 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Wed, Nov 14, 2012 at 9:59 PM, Adam Barth <abarth at webkit.org> wrote:
>>> On Nov 14, 2012 8:59 PM, "Ryosuke Niwa" <rniwa at webkit.org> wrote:
>>> >
>>> > On Wed, Nov 14, 2012 at 8:52 PM, Elliott Sprehn <esprehn at chromium.org>
>>> wrote:
>>> >>
>>> >> I was present for one of the discussions about the exploit and how an
>>> arena like allocator could have helped at Google. One proposed solution was
>>> to allocate all the JS typed buffers in an arena.
>>> >>
>>> >> Is there a reason we can't just do that? It's much less intrusive to
>>> allocate ArrayBuffer in an arena than to allocate all DOM objects in one.
>>> >
>>> >
>>> > I don’t think allocating all JS objects in an arena is good enough
>>> because attackers can inject nearly arbitrary sequence of bytes into DOM
>>> objects (e.g. text node).
>>> The text for a text node is stored in a String, not in the Node object
>>> itself.
>> Yeah, I guess text node was not a good example. Now that I think about
>> it, we can probably get most of security benefits of using RenderArena for
>> DOM if we can allocate all strings & js objects from arena.
> You still have every other object type available to find useful
> overlapping attributes. At best taking away JS objects is an annoyance and
> will probably never make something impossible to exploit. On the other hand
> DOMobjects in their own size class you would likely have many situations
> where exploitation is actually not possible. I would much prefer that we
> find a way to accomplish this with specific dangerous types rather than
> just take away objects that make exploitation trivial.

Fair enough.

On somewhat related question, how would you define "DOM objects"? There are
many ref counted objects in WebCore that may not necessarily be exposed to
the Web directly yet contain (derivatives of) page contents. Should we
slab-allocate all such objects? Or are you specifically concerned about
anything inherited from WebCore::Node / TreeShared?

In other words, why are you interested in using the proposed allocation
mechanism for only DOM nodes/objects instead of everything in

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121114/7a5233e6/attachment.html>

More information about the webkit-dev mailing list