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 <cev...@chromium.org> wrote:

> On Thu, Nov 15, 2012 at 12:34 AM, Elliott Sprehn <espr...@chromium.org> wrote:
> 
> On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans <cev...@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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to