* One Thousand Gnomes <[email protected]> wrote:
> > We could keep heap metadata as R/O and only make it R/W inside of
> > malloc() itself to catch corruption more quickly.
>
> If you implement multiple malloc pools you can chop up lots of
> stuff.
I'd say that a 64-bit address space is large enough to hide buffers in
from accidental corruption, without any runtime page protection
flipping overhead?
> In library land it isn't just stuff like malloc, you can use it as a
> debug weapon to protect library private data from naughty
> application code.
>
> There are some other debug uses when catching faults - fast ways to
> do range access breakpoints for example.
I think libraries are happy enough to work without bugs - apps digging
around in library data are in a "you keep all the broken pieces"
situation, why would a library want to slow down every good citizen
down with extra protection flipping/unflipping accesses?
The Valgrind usecase looks somewhat legit, albeit not necessarily for
multithreaded apps: there you generally really want protection changes
to be globally visible, such as publishing the effects of free() or
malloc().
Also, will apps/libraries bother if it's not a standard API and if it
only runs on very fresh CPUs?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
