memguard(9) rewrite, part 2

mdf at FreeBSD.org mdf at FreeBSD.org
Thu Jul 29 17:01:40 UTC 2010


Back in March I asked about interest in a memguard(9) redo.  I've had
the time to get the code to a place I'm pretty happy with, and we've
successfully used it at work without running into some of the resource
limitations that the original memguard(9) gave.

http://people.freebsd.org/~mdf/bsd-memguard.diff

The gist of the new implementation is to reserve a lot of KVA for
memguard(9) to use, and then to avoid re-using KVA as long as
possible.  Rather than keep the physical pages around, though, on
free(9) the pages are returned to the system.  The KVA is allocated
using vm_map_findspace() from a current pointer into the memguard_map,
which is incremented until the end of the map is encountered, at which
time it wraps.  This is a "free" way to avoid re-use of KVA as long as
possible; any other scheme requires more than O(1) data to track what
has been used.

I've limited the KVA to 2x ram size, and also limited the physical
memory that memguard(9) can take to vm_memguard_divisor fraction of
physical memory (instead of limiting both KVA and physical to
vm_memguard_divisor as the original code did).

This patch also allows for tweaking which malloc type is guarded at
run time, will randomly guard allocations of any type if requested,
has a knob to always guard allocations of PAGE_SIZE or larger since it
won't waste any memory, will optionally add guard pages of unmapped
KVA at the beginning and end of the allocation to catch overruns more
easily, and also can impose minimum allocation sizes on guarded memory
so that the page promotions don't waste too much space.

Assuming alc@ is happy with the VM changes and no one has any further
suggestions, I'd like to commit this some time next week.  I'd also
like to MFC to stable/8 and stable/7 since this patch doesn't
introduce any KBI/ABI/KPI/API changes.

Apart from the general desire to have production systems run as fast
as possible, I'd really like more tools like memguard(9) to be
always-on, to help catch bugs the first time instead of requiring
multiple recreates.

Thanks,
matthew


More information about the freebsd-arch mailing list