This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Allow explicit shrinking of arena heaps using anenvironment variable


>> I don't see the difference in MADV_FREE and mmap+MAP_FIZED+PROT_NONE
>> over top of the original map. If the latter is not fast enough it
>> should just be optimized for this special case since portable software
>> will already be using it for this purpose.
>
> They differ in the semantics they guarantee, though not in the apsect
> that malloc cares about (when not in the __libc_enable_secure case).
> With MADV_FREE, the kernel is not obliged to do anything at all, it can
> just do nothing at all or it can just mark internal data structures, or
> it can actually reclaim the pages right away--whatever it thinks is
> optimal.  With mmap, the kernel is required to immediately flush the
> pages so that any access is guaranteed to fault as soon as mmap returns.
> That could be much more expensive.

If I understand correctly, security paranoia want to discard pte entry
immediately likes MADV_DONTNEED otherwise it do nothing if system have
much much memory.

Example, if the process crash after MADV_FREE, security sensitive data
may store into core file.

... but, I don't understand the benefit of this proposal. nowadays,
security paranoia always do zero clear before calling free for
sensitive data. Can anyone please tell me which programs get a benefit
from this change?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]