>>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
