Bug 309598 – Libpas should quickly use bitfit heaps when retag-on-scavenge is enabled & when possible to do so

• Status: RESOLVED
• Resolution: FIXED
• Component: bmalloc

[Marcus Plutowski]

rdar://172220367

Retag-on-scavenge functionally supports both segregated and bitfit heaps. Bitfit allocations, however, are tagged immediately when the object is freed.
As such, when retag-on-scavenge is enabled, we should prefer to allocate from bitfit heaps to exploit this property -- the exception of course being isoheaps, due to the intrinsic type-unsafety of bitfit heaps.  

Notably, this already kinda happens in privileged processes, where WebCore enables fastMiniMode during process setup. However, this happens late enough that several local-allocators are able to first allocate objects, populating a goodly number of segregated size-directories which can thereafter be used for allocating segregated objects. This isn’t a problem for mini-mode because the goal there is just to reduce memory usage, so some stray allocations aren’t going to crater the feature, but for us it is — the security boundary provided by any eventual retag-on-free solution would be much weakened if attackers could go through objects allocated sufficiently-early-on. 

So concretely, this bug requires two things:
  1. Extend the “mini-mode”-style segregated-heap disablement to cover WebContent processes when Retag-on-Scavenge is enabled;
  2. Hoist this enablement to early enough in the process lifetime that no segregated directories can sneak by before we disable them.
             
This will get us part-way from retag-on-scavenge to rdar://125176920; the remaining component would be to disable isoheaps.

[Marcus Plutowski]

Pull request: https://github.com/WebKit/WebKit/pull/60301

[EWS]

Committed 309573@main (dee9781145cf): <https://commits.webkit.org/309573@main>

Reviewed commits have been landed. Closing PR #60301 and removing active labels.