Consensus on allowing tunables to use GLIBC_* namespace env vars.

[Florian Weimer]

On 09/04/2015 05:06 AM, Carlos O'Donell wrote:

> - Allow patches that control glibc behaviour via environment
>   variables, subject to tunables rules, and good design.
>   
>   - Even though internal tunables API is not yet done.

Environment variables affect process trees, and can only be set at
process start time.  Is this really the behavior we want?  The advantage
is that it's not system-wide, but that's the disadvantage as well.

The presence of environment variables changes stack alignment and where
cache line boundaries fall on the stack.  For performance tunables, this
can be problematic because the effect from setting the environment
variable itself can easily outrank the impact of the actual tuning change:

Todd Mytkowicz, Amer Diwan, Matthias Hauswirth and Peter F. Sween,
“Producing Wrong Data Without Doing Anything Obviously Wrong!”.
ASPLOS, March 2009.
<http://www.inf.usi.ch/faculty/hauswirth/publications/asplos09.pdf>

> - Use an env var namespace prefix of GLIBC_* for all tunables.

LD_* might benefit from some existing security filters.  Maybe that's
sufficient for staying within that namespace?

-- 
Florian Weimer / Red Hat Product Security