How hard is it to adapt a memory allocator to CHERI?

It's quite good fun to see which software runs with this extended allocator - assuming you've got enough RAM! The Bump Allocator and CHERI purecap What does it mean to run an allocator under CHERI? Let's start by assuming we're using "Pure capability" CHERI. For our purposes, that means that 64-bit "Pointers" become 128-bit capabilities, where the additional 64-bits contain various permissions. The clue to where those bounds comes from is that they span 1GiB of memory - exactly the same quantity of memory our bump allocator requested from mmap. What Should an Allocator do on CHERI purecap? Our bump allocator works without changes on CHERI purecap, but gives little meaningful security improvement relative to a non-CHERI system. This code executes successfully with our original bump allocator on CHERI purecap, but is terminated with a SIGPROT with our adapted bump allocator. Only one allocator was invulnerable to these simple attacks - and the default CheriBSD allocator, a jemalloc fork, was vulnerable to 3 of them! We didn't even try that hard to find such attacks - it seems likely to me that more attacks on CHERI purecap allocators could be found if someone has the time to investigate further. Acknowledgements: my co-authors on Picking a CHERI Allocator did all the hard work and generously offered comments on this post. First, some people really need their programs to run faster and are prepared to buy a lot of RAM to make that happen - yes, this really does happen! Second, sometimes we want to know what the relative proportion of time we spend in an allocator is - our simple bump allocator gives us a good idea of the "Intrinsic" costs of a program with the allocator factored out.