Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool.

The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet.

I've seen discussions on adding an additional memory tag to CHERI for memory in quarantine, but I dunno what is best.

Fil-C relies on the compiler being trusted whereas CHERI does not. If we do, then perhaps we could come up with a hardware-accelerated system that is more lightweight than either.

Follow-up: CHERioT (Microsoft's RV32E-based variation for embedded systems) does have a quarantine tag bit per 64-bit word of memory. The base address' bit is checked on capability load by the CPU's "Load filter".

Implementations can always get better, but I think the only categorical (if even that) improvement that will arise depends on careful program design/implementation; that is, reducing the scope and number of capabilities and providing semantic information on capability usage. Fil-C and CHERI do an admirable job of maximizing backwards compatibility and even allowing incremental improvements, but I think it's time that programmers bought into capabilities too.

I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.