Messages in this thread | | | Date | Thu, 7 May 2015 21:26:20 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 00/12] [RFC] x86: Memory Protection Keys |
| |
* One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> 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
| |