1. 5
  1.  

  2. 3

    So it’s an allocator that puts each allocation in its own page and frees pages as soon as the allocation is freed . The performance is apparently not so bad as this approach usually gets, because they don’t have to call mmap()/munmap()/mprotect() to change page tables. They can alter page tables without making syscalls because they are running as a virtual machine (using vtx or svm).

    One question, is the cure possibly worse than the disease? If the page tables are mapped at all times so that they can be altered with low overhead, does that mean that a stray out-of-bounds write could result in something really fun happening such as an attacker-controlled page of memory getting marked as executable?

    I’m sure I saw something on here ages ago about a system that used a hypervisor to grant superpowers to mostly-ordinary user processes, speeding up calls like mprotect(), mmap(), mincore() and in-process page fault handling (for processes that want to do their own virtual memory by handling SIGSEGV signals) by some huge factor. It might have been Dune? https://www.usenix.org/node/170864

    1. 3

      So it’s an allocator that puts each allocation in its own page and frees pages as soon as the allocation is freed.

      Not really. They still place allocations right next to each other in physical memory, with multiple allocations potentially sharing a page. But for each allocation on a physical page, they create a dedicated virtual-to-physical mapping to that page. That way each allocation has its own virtual address range which can be unmapped by free() and never reused (because virtual memory is abundant, unlike physical), but RAM is still used as efficiently as with any other allocator (they actually wrap the system allocator).

      Of course you can still access different allocations sharing a page through each of the virtual aliases, so this does only helps with dangling pointers, not overruns or anything else really.

      Also, their implementation is based on dune.

      Edit: They talk about the issue of mapping the page tables at about 1:40:43 in the recording of the presentation.

      1. 1

        Aha! Thanks for clarifying.