As a long-time systems programmer, I think you’re overstating the problem with type aliasing. Maybe your vendors are just trying to come up with excuses not to use CHERI!

We have compiled a lot of C and C++ codebases. Without supporting type aliasing, very few would work.

CHERI is in a different boat because it has to have a story for language runtimes.

It aims to support all TCB code, because if you don’t have memory safety in your TCB then you don’t have it anywhere.

I’ve yet to encounter a union I can’t fix.

Does that include implicit unions? For example, many consumers of uthash store integers in the void* value slots. A lot of generic data structures in C expose void* or uintptr_t entries and have consumers that store pointers, data, or both.

We have surveyed a lot of exciting C idioms and we support almost all of them. Dismissing things that we’ve seen thousands of times across diverse codebases as not important does not give me any confidence in your approach or your evaluation methodology.

Final thought: I don’t think that the CHERI approach is all that safe. Because it doesn’t prevent type aliasing, it also doesn’t prevent you from writing a custom allocator that vends übercapabilities. For example, did y’all do anything to OpenSSL’s super funny “secure” malloc?

Yes, we set bounds on allocation. The port of OpenSSL was subject to a DARPA-funded red teaming exercise where they reintroduced bugs such as Heartbleed and had professional exploit writers try to break it. They were not able to.

Your custom allocator gets memory from somewhere, whether that’s mmap, malloc, or something a layer down. The thing above will apply bounds, so bugs in nested allocators can affect their consumers but not anything else.

score 4 · canonical

If you store an int to a ptr or a ptr to an int, you trap and die.

We were talking about the case where you have a union of a pointer and an int—that obviously can’t trap and die, right? (That said, I don’t understand why you would trap and die anyway; what are ‘boxed integers’ for if not this sort of thing?)

GC write barrier

Lots of different designs, though you’re right they usually only target pointer stores; but they generally cost a little bit more than that. The main designs I know are: 1) card-mark: unconditional ‘card_table[pointee >> k] = 0’, 2) g1-style region check: ‘if ((pointer ^ pointee) >> k) goto slow’.

score 1 · canonical

Btw, did you consider trying to compress the pointer format by getting rid of the sidecar and using a floating-point format for the bounds? This would require rounding up allocation sizes to match the fp rounding—so e.g. char *x = malloc(big); x[big] might fail to trap—but that doesn’t seem like an awful tradeoff.

score 1 · canonical

In terms of language semantics, CHERI doesn’t really enforce anything on its own. When you target CHERI, you choose how to use its primitives to enforce whatever properties you want to enforce. CHERI allows ptr->int->ptr because C mandates it.

For example, because CHERI allows ptr-to-int-and-back “transmutations”, you could write code on top of CHERI where you have a custom alloc and all of your pointers end up having enormously powerful capabilities. (Plz correct me if I’m wrong.)

I don’t quite understand this. Even without ptr->int->ptr casts, an alloc implementation could certainly choose to return very powerful capabilities, as powerful as whatever the allocator itself has access to. But you’d probably choose to use an alloc implementation that doesn’t do that, just as one can choose whether to use Fil-C or not.

score 1 · canonical

For example, because CHERI allows ptr-to-int-and-back “transmutations”, you could write code on top of CHERI where you have a custom alloc and all of your pointers end up having enormously powerful capabilities. (Plz correct me if I’m wrong.)

You are wrong :-).

Nothing in CHERI (including assembly) can bypass the capability model and we have proofs of this run against the formal model of the ISA. We allow pointers to be round tripped at intptr_t because not supporting that breaks basically all non-trivial C code, but doing so does not amplify rights. It remains a capability with the same bounds and if your arithmetic takes it out of bounds then that’s fine, but you can’t dereference it while it’s out of bounds (taking it too far out of bounds will make it unrepresentable and unable to be used as a capability) . This is important because we’re building a model that is a foundation for higher-level security abstractions.

If the same memory location is used for a pointer and an integer, the hardware guarantees atomicity with respect to the capability and its tag bit, so any data store (even a single byte) destroys the capability.

If you can’t do these things, you break C idioms that most non-trivial programs depend on. We did a lot of work with formal models of C and surveys of C codebases and programmers to identify a de facto C specification that encapsulated expected C behaviour.

Fil-C, being a language change, allows for the introduction of thin pointer annotations later, and those annotations could be made to be memory-safe. And, those annotations would eliminate substantially all of the overhead of Fil-C in those places where you used them. I think CHERI would have no answer to that, in the sense that Fil-C code that used those annotations wouldn’t have a good story for how to compile to CHERI and still get all of the safety guarantees.

Early versions of CHERI C used a hybrid ABI where some pointers were annotated and others were not. Annotated pointers are capabilities, the rest are integers relative to the default data capability. We found that the friction in adopting the hybrid model was more than an order of magnitude higher than the overhead of recompiling in pure capability mode. We can compile large (multi million line) C and C++ codebases with pure capability mode with small changes (often none), whereas annotating the pointers that want dynamic checks was a lot more work. Our tcpdump changes, for example, to bound packet buffers required around 700 lines of diffs, to build as pure cap required four. Most of the changes for pure-cap mode are easy to upstream because they’re things like using uintptr_t instead of size_t for things that round trip pointers through integer types (which is what C requires anyway). Changes like this have been upstreamed to git, a bunch of KDE projects, and so on.

So, we can do that, but it’s rarely a good idea. You end up with the annotations needing to flow through the code and it becomes a data-flow problem. C programs like to do things like put void* pointers in heterogenous collections and this is very painful if you have two kinds of pointer.

We now recommend that no one use the hybrid ABI because it starts off looking simpler (‘look, I can make these changes incrementally’) but ends up being more work in the end.

Note that this does not always apply to other languages. For example, Java and JavaScript VMs can use 32-bit pointers, left shifted by two or three, as object pointers. They are interpreted as relative to a safe-heap capability and can be bounded based on the dynamic type when passed FFI code. We do the same on a smaller scale with Microvium on CHERIoT: the JS runtime uses a semispace compacting heap and uses 16-bit offsets as JavaScript pointers. When it passes them to C code, it removes store permission and sets the bounds, so C code cannot violate the JavaScript invariants.

score 6 · canonical