Bug 163375 – We should consider allocating a CodeBlock's Instruction stream away from other things

• Component: JavaScriptCore
• Status: NEW

[Saam Barati]

For example, any buffer overflow of something else allocated in bmalloc's heap has the potential for writing over a CodeBlock's instruction stream.
This isn't a full-proof defense, but if we can do it at no extra cost, we should, since it will make buffer overflows in bmalloc's heap less obviously exploitable.

[Filip Pizlo]

I wonder if we could add API to bmalloc to do this.  It would force those objects to be allocated from their own size classes.  If they get large, they would be allocated with guard pages around them, automatically.

Something like:

Foo* createFoo()
{
    static SeparateMallocSpace mySpace;
    return static_cast<Foo*>(fastMallocSeparate(mySpace, sizeof(Foo)));
}

[Oliver Hunt]

I'd like a generalized version of this so that we could have (for example) RenderObjects allocated separately from DOMObjects separately from StringImpls

[Geoffrey Garen]

I don't think it's practical to do this in a general-purpose way because each unicorn object class, which refuses to share memory with other object classes, linearly increases fragmentation, memory footprint, cache non-locality, TLB misses, and paging.

In my experiments with MallocBench and bmalloc, too much separation between object types introduces significant performance cost, and I invested a lot of effort to avoid that cost.

It might be practical to do this in a special-purpose way, as long as it's only for a small number of object types, and we only request a best-effort separation and not a permanent guaranteed separation.

Phil's fastMallocSeparate API, with best-effort service, is trivial to achieve using bmalloc's "Cache" class as the type for "mySpace", and we could probably service the CodeBlock instruction stream, the render tree, and the DOM tree that way without penalty.

[JF Bastien]

IIUC PartitionAlloc was built to do this:
https://chromium.googlesource.com/chromium/blink/+/master/Source/wtf/PartitionAlloc.h

IIRC it was purely for security, but was deployed with claims of performance wins.

Chris Rohlf forked it a short while ago with the goal of cleaning+tuning some things and adding interesting hardening:
https://github.com/struct/HardenedPartitionAlloc

[Geoffrey Garen]

(In reply to comment #4)
> IIUC PartitionAlloc was built to do this:
> https://chromium.googlesource.com/chromium/blink/+/master/Source/wtf/
> PartitionAlloc.h
> 
> IIRC it was purely for security, but was deployed with claims of performance
> wins.

I would love to see some data to back up those claims.

I'm tempted to explain in advance why those claims must be false, but we might as well skip that step and just look at the data -- or lack thereof.