[Veserv]

Handling fragmentation is likely the bigger problem. There are some questions about revokation, demand paging, and probably some other things that I am forgetting, but most of those have potential, non-intrusive solutions.

However I have not seen anything that effectively handles fragmentation. Maybe you could do some sort of transparent compaction in conjunction with “demand paging” in the relocated area, but that would be very intrusive and likely only provide runtime guarantees like a system using a compacting GC.

[nullc]

> There are some questions about revokation,

I'm not sure what you mean by questions. But cheri does have an answer to how revocation works: All cheri capabilities (pointers) are tagged and the tags are controlled with protected instructions. To revoke a capability, you can sweep the tagged memory and untag any revoked cabability. To reduce revocation work, you can defer reusing cabilities for as long as reasonable and then revoke many in a single sweep.

Of course, this is not cheap compared to the rest of cheri-- but they do have an answer to it, and it's implemented e.g. in cheribsd. It's intrusive (at least in terms of performance/latency) as you note, though it's distinct from most other GC approaches because it's secure even against malicious code, and can't have false positives or false negatives (because tags are completely unambigious).

One of the cool things about cheri is that it eliminates the need for a TLB for security reasons which could have positive performance effects... unfortunately virtual memory is still needed for virtual memory that exceeded physical memory. Though for an IOT-ish device swap is probably a non-issue.

[Veserv]

Revokation that demands a full memory sweep is problematic in high security use cases, but potentially workable.

Which is my point about questions; there exists a potential solution but it remains to be seen how effective it would be in the circumstances.

Personally, I think they should probably implement a two-level capability. The kernel presents a top-level capability during allocation requests which userspace can then derive from at will. Kernel revokation of the top-level capability would revoke any derived capability. The derivation relation can almost certainly be stored in the tag resulting in no additional space requirements per-capability. At worst you could add some additional hardware machinery to support efficiently managing and resolving the derivation relation.

But again, potential solutions with some questions around usability.