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


On Sat, Jul 21, 2012 at 07:56:40AM +0530, Siddhesh Poyarekar wrote:
> On Fri, 20 Jul 2012 15:23:45 -0700 (PDT), Roland wrote:
> > Like Carlos, I want to hear about the motivation for this.  I really
> > don't like adding to the plethora of environment variables and other
> > knobs affecting malloc.  We have too many of those as it is.
> 
> To be honest, the problem it solves for me is just the fact that it
> shows up correctly in the maps and simulates the main process heap
> more closely. I do understand that only this is a bad reason to add an
> extra environment variable, which is why I had to look for a second,
> more useful reason to do this, which is giving regular programs the
> extra security that setuid programs get by dropping protection for
> unused sections of the arena.

It does not give regular programs extra security. The "security"
benefit for suid programs is that data freed before the program drops
privileges has a better chance of being obliterated by the time
privileges are dropped, at which time there's a good possibility that
the real user who invoked the program might be able to access its
memory.

The more useful benefit is that unused space in the arena is actually
returned to the operating system in 2 senses:

1. The application no longer retains dirty pages containing junk data,
which means junk data won't get swapped to disk later (a very costly
and wasteful operation).

2. Since the virtual addresses are no longer dirty and no longer
writable, they no longer consume commit charge. This makes the
corresponding amount of memory available to other applications.

In my opinion, this behavior should always be enabled regardless of
whether the program is suid or not. No need for an environment
variable. We do something similar in musl libc's malloc
implementation, but without the PROT_NONE aspect, which means we only
get benefit #1 but not #2.

Rich


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