[HN Gopher] How hard is it to adapt a memory allocator to CHERI? ___________________________________________________________________ How hard is it to adapt a memory allocator to CHERI? Author : todsacerdoti Score : 40 points Date : 2023-09-18 09:54 UTC (13 hours ago) (HTM) web link (tratt.net) (TXT) w3m dump (tratt.net) | foamdino wrote: | We're working with the Morello processor and have had to wrestle | a bit with allocation from a block based allocator: | https://medium.com/thg-tech-blog/morello-and-memory-pools-91... | saagarjha wrote: | It would be nice to have a "part 2" of this where a more complex | allocator was discussed that does more interesting things like | have intrusive metadata or have heap block headers. For example, | you probably do not want to hand out a pointer with a capability | to alter its own heap header, but on free you'll get that pointer | back and it won't have the capability: how do you safely use that | context to modify your metadata again? How do you protect | freelists? There's lots to explore. | dwattttt wrote: | Perhaps we'll see allocators hold a heap/bucket pointer + | capability; you would use the "free" pointer to find the | metadata, and the heap pointer to interact with it | wahern wrote: | Some more security conscious allocators have already moved | away from adjacent metadata storage to mitigate heap | overflows. Instead, the metadata is stored in separate ASLR'd | allocations and indexed by the pointer value. Some metadata | might be implicitly encoded in the pointer value (e.g. by | alignment or position above/below some virtual memory | demarcation) to optimize lookup of the metadata. | LoganDark wrote: | IIRC, the allocator would possess a capability with authority | over the whole heap, and it can derive a new pointer using that | capability and the address of the block that's being freed. | | Obviously, it should make sure that the capability passed to | free has full authority over the block first, or else it may | end up vulnerable to confused deputy attacks. ___________________________________________________________________ (page generated 2023-09-18 23:00 UTC)