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

Eric Seidel eric at webkit.org
Tue Nov 13 22:23:43 PST 2012

RenderArena was a perf optimization for the rendering tree, which
hyatt imported from Mozilla 10 years ago:

The prevailing lore has long been that RenderArena is no longer
useful, ugly, and should be killed!

The (unfortunate?) reality is that we've failed to do so, despite
trying several times.

However, like those bell-bottoms in your father's closet, RenderArena is back
in vogue and Chromium's security team very excited about
RenderArena's security benefits.

Why, you might ask?

Slab-allocators (i.e. RenderArena) hand out memory all from a single
region, guaranteeing (among other things) that free'd objects can only
be ever overwritten by other objects from the same pool.  This makes
it much harder, for example to find a Use-After-Free of a RenderBlock
and then fill that RenderBlock's memory (and vtable pointer) with
arbitrary memory (like the contents of a javascript array).

We're aware of multiple high-profile past WebKit exploits (including
the last $60,000-winning Pwnium 2 exploit) which would have been
defeated by a Slab-allocated DOM.

Various members of Chromium's security team have also been working on
improving RenderArena:

Since RenderArena is generic, the current plan to move it to WTF (as
by Chris Marrin suggested back in
clean up the code further, and investigate wider deployment (like to
the DOM tree) for the security benefit and possible perf win.

Also on the list is making our smart-pointers (OwnPtr,ReftPtr)
smarter, to avoid the current manual use/free mess of current
RenderArena clients.

Personally, I hope we bring back mullets next.

More information about the webkit-dev mailing list