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

[Oliver Hunt]

Since a common theme people are bringing up is vtable overrides, I do recall reading about vtable masking being available in some compilers.  I'm wondering if we should push for support for such in compilers we use - I'm not sure what the vcall perf hit is in such cases, but it would knock kill off vtable overwrites as an attack vector.  We can also trivially add vtable poisoning to dealloc if we felt it necessary - i'm not sure here if the problem is specifically use-after-free, use-after-free-and-overwritten-with-evil-data, or use-after-free-and-overwritten-with-another-object-with-a-different-type.

--Oliver

On Nov 15, 2012, at 2:08 AM, Chris Evans <cevans at chromium.org> wrote:

> On Thu, Nov 15, 2012 at 12:34 AM, Elliott Sprehn <esprehn at chromium.org> wrote:
> 
> On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans <cevans at chromium.org> wrote:
> 
> ...
> 
> My read on the Arena is that it's fragmentation resistant (i.e. it will not repurpose a larger free chunk to satisfy a smaller allocation.) However, memory usage at any given time is defined by peak usage since it cannot release pages back to the system without ruining its security guarantee. Interestingly, it can't be super bad: we already bite this bullet for RenderArena as used by RenderObjects. The RenderArena lifetime is the same as the document / DOM and I was surprised to recently be told that we don't throw away the RenderArena on a full layout.
> 
> 
> My understanding is that the render tree is rather small compared to the DOM in terms of memory usage on most pages
> 
> This does not seem to necessarily be the case.
> 
> Loading Gmail to the inbox view, sizes in bytes for all live allocations:
> - 541k in the DOM arena
> - At least a 918k plus a 49k render arena. May have failed to count a few smaller ones that are still live.
> 
> Would you like similar measurements for a simpler page? Or some other complicated page you think might be instructive?
> 
> 
> Cheers
> Chris
> 
> so not releasing it may not be so bad, but never releasing the memory used from DOM nodes seems like it'd be bad for large web apps.
> 
> - E
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121115/ad81d04f/attachment.html>