[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)