tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: libphkmalloc? (Was: CVS commit: src/lib/libbsdmalloc)
>>> I wonder if it's time to retire libbsdmalloc?
>> Amusingly, I recently used the classical BSD malloc [...]
> But see https://phk.freebsd.dk/sagas/phkmalloc/ for the motivation
> and the story, including the pathologic paging the original malloc
> causes.
It's a pity traps to the kernel are so expensive. That would make it
possible to keep malloc overhead completely safe from wild memory
accesses by the affected program. Maybe it'd be worth it for a
debugging mode, where performance takes a back seat to finding memory
use bugs?
I'm not sure it'd be worth the additional exposed attack surface in the
kernel, though. I'd have to think about possible ways to address that.
I did more or less that in my SPARC userland emulator; I fiddled libc
to do an emulator detect and, if running emulated, malloc-family calls
are traps to the emulator. This lets me keep malloc overhead
completely outside the emulated program's address, not even
addressible, much less accessible. (It also lets me implement redzones
accurate to the byte before and after malloc blocks.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index